[Feature] Exclude packages from installation

[tido64]

• I'd be willing to implement this feature (contributing guide)
• This feature is important to have in this repository; a contrib plugin wouldn't do

Describe the user story

Every now and then, I get a security alert for a package or some package pulls in a random, unused dependency that pollutes the repository and the fix is to simply not install the offending package.

Today, we're solving this by creating a stub package and using resolutions + link: (example) to force resolving the package to our stub instead. We're thinking of formalizing this as a plugin, using the ignore: protocol, and was wondering if this would be of interest in Yarn.

Describe the solution you'd like

Upon finding ignore:, Yarn can create a stub package and link it during installation.

Describe the drawbacks of your solution

Obviously, this will break if the package is actually used. But since you've explicitly added ignore:, it should be undoable.

Describe alternatives you've considered

We are implementing this as a plugin in any case but was wondering if this is interesting upstream.

[NormalGaussian]

I was going to suggest you patch it, but that doesn't appear to work (https://github.com/NormalGaussian/yarn4-patch-out-deps-repro demonstrates patching not affecting dependency installations), and even if it did, it would result in an error being thrown on import.

The existing workaround - using resolutions to load the local 'ignore' package - results in something very specific: it loads a package with an index.js that exports an empty object. This means:

• it does not error when the main path is loaded (import ... '@rnx-kit/ignore';).
• it will error for other import paths (import ... '@rnx-kit/ignore/subfile.js';).

For 'ignore' to become generic at the package manager level, I'd imagine it would need to handle all of the import paths in the same way?

And to clarify the need here;- these are dependencies that are valid on the package, just not used by you?

[tido64]

In the cases where we've used this, the dependency is not used either because it was supposed to be a devDependency or require additional changes on the user side, for example with configuration. If we hit cases where there are deep imports and our stub would fail, I suspect we would just not link the stub and look for some other workaround. I don't know if it's meaningful for a stub to able to support other import paths like you've described.

[NormalGaussian]

It being an incorrectly marked devDep is more clear cut. Being able to remove it from the tree entirely and not stub at all would be much simpler, giving a more consistent result; any imports would then error.