[RRFC] opt out of optional meta-dependency

[isaacs]

Let's say you depend on small-pkg, which has an optional dependency on large-pkg.

You wish to use small-pkg, but do not wish to use large-pkg (and small-pkg works fine without it).

There is no easy way right now to do this, without opting out of all optional dependencies.

Some possible approaches to explore:

• Add a dependenciesMeta field, with optional: false as one of the flags, indicating that optional dependencies of that dependency should not be loaded. Example:

  {
    "dependencies": {
      "small-pkg": "1.x"
    },
    "dependenciesMeta": {
      "small-pkg": {
        "optional": false
      }
    }
  }

  One question here would be: what happens if some other package has a dep (optional or otherwise) on large-pkg. I'd assume that it'd be installed in that case, and the optional dep satisfied. But the optional dep relationship itself would not be sufficient to trigger its inclusion.

• Blacklist specific modules that should never be installed. Then, if they are an optional dep of something in the tree, that'll block them from installation. If they are required, then it'll fail.

  {
    "dependencies": {
      "small-pkg": "1.x"
    },
    "blockList": [
      "large-pkg"
    ]
  }

  This raises the question as to what happens if the module is installed as a dependency, where the root package does depend on large-pkg. In that case, should the install fail? And if so, this becomes a very powerful (and potentially annoying) footgun for creating dependency hells.

• Optional deps that are not installed by default. This was brought up in acceptDependencies package.json field #72, and the use of peerDependencies for this purpose was raised in Let's install peer deps again! #43. It would be nice for publishers to indicate that they have an optional dependency, but that it should not be installed by default.

  One way to do this today is to simply not list the dependency, but this is not compatible with pnpm, berry, or pnp. Also, it can cause the package gett the wrong version of a dependency, and having no way of inspecting this by examining the tree, so it has to not just conditionally load the dep, but also check its version manually, which is a lot of work.

  This could be expressed as an acceptDependencies entry setting the spec to null, as suggested in acceptDependencies package.json field #72. The semantics there are "I am fine with large-pkg not being found in the tree, but I have a dependency on 1.x if it is there." In other words, it will "dedupe" against the absence of the package, and not fetch it; but if there is a version present, and it's not 1.x, then it'll fetch a satisfying version.

[ljharb]

It seems like there's two useful things here:

1. a package X that optionally depends on Y should be able to say "don't install Y by default when you install X"
2. a package that installs X (directly or transitively) should be able to say "don't install Y when installing X"

A flat block list doesn't seem sufficient; since dep trees can be nested, the configuration here would probably need to support nesting too.

dependenciesMeta seems like it would work for both of the two use cases, and would let consumers override their dependencies' configurations?

[wesleytodd]

Related: #120

I think most cases of optional deps (if not all) fit into what is described in #120 right? I am not sure how much I like any of the proposed solutions, but the problem for sure exists.

I think "dont install by default" is the best option with the addition of:

It would be nice for publishers to indicate that they have an optional dependency, but that it should not be installed by default.

[isaacs]

I think that "the consumer wishes to install X but not X's optionalDependency Y" is either addressed by --no-optional or belongs somewhere in the vicinity of #129. Let's focus on the "X has an optional dep on Y, but Y should not be installed by default".

I assume that the full constraint statement here would be something like: "X has an optional dep on Y@spec, and Y should not be fetched by default, but if Y is present in X's dep tree, it must satisfy spec". Am I interpreting that correctly? (I'm thinking, if you don't care what version something is, and don't need it to be there, you can express that really efficiently by just not making it a dep at all.)