From ed7ce57106ffe086b574723a428ee6b526f6169f Mon Sep 17 00:00:00 2001 From: Rhys Arkins Date: Sat, 27 May 2023 15:33:34 +0200 Subject: [PATCH] Update docs/usage/configuration-options.md --- docs/usage/configuration-options.md | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/docs/usage/configuration-options.md b/docs/usage/configuration-options.md index d400e1d58f4778..4bbd2a53c5e0d1 100644 --- a/docs/usage/configuration-options.md +++ b/docs/usage/configuration-options.md @@ -610,16 +610,15 @@ When `constraintsFiltering=strict`, the following logic applies: - Does this package's release declare constraints of its own (e.g. `engines` in Node.js)? - If so, filter out this release unless the repository constraint is a _subset_ of the release constraint -Here's some examples of when a release is allowed: - -- The `package.json` declares its `engines.node` as `18` which is a subset of the package release `16 || 18` -- The `package.json` declares its `engines.node` as `^18.10.0` which is a subset of the package release `>=18` -- The `package.json` declares its `engines.node` as `^16.10.0 || >=18.0.0` which is a subset of the package release `>= 16.0.0` - -Here's some examples of when a release is filtered out (disallowed): - -- The `package.json` declares its `engines.node` as `>=16` while the package release has a narrower `16 || 18` -- The `package.json` declares its `engines.node` as `16` while the package release has a narrower `^16.10.0` +Here are some examples: + +| project | dependency | result | +|--------------------------|--------------|----------| +| `18` | `16 \|\| 18` | allowed | +| `^18.10.0` | `>=18` | allowed | +| `^16.10.0 \|\| >=18.0.0` | `>= 16.0.0` | allowed | +| `>=16` | `16 \|\| 18` | filtered | +| `16` | `^16.10.0` | filtered | When using with `npm`, it's recommended: