Yarn: [FR] a way to ignore packages

Created on 2 Oct 2017  路  17Comments  路  Source: yarnpkg/yarn

Right now in npm or yarn it's impossible to ignore packages.
This makes it very difficult to package small node_modules folder.

Let me explain:
In my apps i use many packages, some for which i need to keep optionalDependencies like noble. Some i dont want and which makes the node_modules folder a lot bigger, like log4js optional dependencies.

The consequence of that is that i can't use --ignore-optional.

So for example if i want, after a yarn install --flat --prod cleanup and remove log4js optionalDependencies, i simply cant! I would need to get the dependency tree for all the optional modules, make sure there are not used by anyone else, and then remove the folders manualy.

The best solution, even if not perfect, would be to be able in the package.json to add "ignored" packages. Those would be ignored in yarn install and thus would not alter the dependency tree.
I would then simply have to add all log4js optional dependencies in my ignored section.

Would that be possible?

Most helpful comment

Another use case - fsevents:

A yarn.lock file generated on a Mac will include this dependency, so when code is deployed to a CI system running ubuntu, yarn finishes with an exit code 1. It would be nice to ignore this dependency in a particular environment.

All 17 comments

I second this request, both to manage package size and also to suppress misbehaving optional packages.

The Problem
To elaborate, a package we rely on (good-package) has an optional dependency (bad-package) with unmanaged dependencies. That is, bad-package requires you to separately download and build some libfoo before running yarn install, which we never do because bad-package isn't useful to us. Unfortunately, this causes yarn install to always spew a lengthy warning when bad-package fails to install.

This optional dependency is obviously misbehaving, but we can't fix it, so instead we'd like to ignore it. We can't just use --ignore-optional everywhere, because we do need some optional dependencies like fsevents.

The Suggestion
I suggest the repeatable flag --suppress-optional <package-name>, which would cause <package-name> to be ignored if <package-name> is a purely optional dependency, and would cause an error if <package-name> is actually required.

(For reference, see yarnpkg/yarn/pull/5059 for discussion of when a package is truly optional...)

Also, could we edit the title for clarity: Add way to ignore individual optional packages?

@tvald i am not sure about the title cause maybe you you want to ignore non optional packages too!

If a non-optional package were suppressed, that would presumably break all packages which directly or transitively depend on it, including the top-level package.

It would be great if you can illustrate a case where a non-optional package can be suppressed without breaking things. Otherwise, I'd prefer the smaller and safer capability to suppress only transitively optional packages.

Do note that a required dependency of an optional dependency is considered optional, unless referenced elsewhere (again, transitively) as required.

@tvald node-pre-gyp is one simple case. it comes with a lot of unecessary data for production.
I already ignore it by removing it. And in my package.json i include my own package to replace it which only include what s necessary for production.

That's far more complicated, then. I'll split off a separate feature request if that's the kind of scenario you want to support with this issue. /shrug

Another specific use case for this feature was raised in https://github.com/firebase/firebase-js-sdk/issues/546#issuecomment-370596013

Namely, firestore is an isomorphic package that includes large platform specific dependencies. If you are using their package for a website, it would be nice to able to tell yarn that it can ignore the dependencies that aren't specific to that platform.

Another scenario where this can help is with Node.js usage on AWS lambda. Lambda has a 50MB code limit. Many packages (including one created by our team, for example) tend to include a large dependency tree. To fit into the space limit, one would tell yarn to ignore certain packages, assuming you know what you are doing and are ignoring only dependencies that you are not using in your code.

Another use case - fsevents:

A yarn.lock file generated on a Mac will include this dependency, so when code is deployed to a CI system running ubuntu, yarn finishes with an exit code 1. It would be nice to ignore this dependency in a particular environment.

Still not a thing? I'm having problems rn with chromedriver getting overridden while bootstrapping, and I don't want that because it breaks while trying to download the .zip (behind corp proxy). So I want to tell yarn not to touch chromedriver, so it does not override my local modifications that should make it work -_- (I mean, I read through chromedriver/install.js, and I did what it does by myself in like twenty seconds...)
Please tell me if you have a workaround, though

Some package have multiple function, and if I only use part of them, then some required dependencies can suppressed.
Currently we can use tools like rollup to do this After install.

(馃 ok, I think this is rare)

I'm using gulp-sass, it's default to use node-sass, also can config to use sass instead.
But they write node-sass in dependencies... 馃挗

if I only use part of them, then some required dependencies can suppressed

Definitely a reasonable use case that I have encountered. We also use rollup in the build stage to reduce build artifact size.

Now look at my stupid.json: 馃ぃ

{
    "name": "test",
    "version": "1.0.0",
    "private": true,
    "license": "WTFPL",
    "dependencies": {
        "debug": "^3.2.6"
    },
    "optionalDependencies": {
        "ms": "https://registry.npmjs.org/package-that-cannot-be-installed/-/package-that-cannot-be-installed-0.0.0.tgz"
    },
    "resolutions": {
        "ms": "https://registry.npmjs.org/package-that-cannot-be-installed/-/package-that-cannot-be-installed-0.0.0.tgz"
    }
}

This will install debug without required ms dependency

Adding directly to @GongT's comment and since this issue is still open. I've released my own version of a similar idea but unlike the pacakge-that-cannot-be-installed package, this one doesn't force the usage of the --ignore-scripts flag for yarn install.

You can find it here:

Implementation:

{
    "name": "stupid.json",
    "version": "1.0.0",
    "private": true,
    "license": "WTFPL",
    "dependencies": {
        "debug": "^3.2.6"
    },
    "resolutions": {
        "ms": "https://registry.yarnpkg.com/@favware/skip-dependency/-/skip-dependency-1.0.2.tgz"
    }
}

Honestly don't ask me why. I don't know. It just bothered me that the previous one required --ignore-scripts 馃ぃ.

Sidenote: it does really work. I was able to filter out jest-environment-jsdom from a pure NodeJS application as a test, yeeting out 5MB from the node_modules folder. If you're crunching for space this can help I guess.

This is also something needed for my project which is suffering from issues with scrypt.js and node 12.

Would love to install https://www.npmjs.com/package/ganache-core with --ignore-optionals set permanently.

Jest doesn't need babel anymore, so I'd love to suppress the need to download that sprawling set of dependencies even before Jest is prepared to remove it as a dependency (though it wouldn't be employed, by configuration).

I'm building a Lambda function that has a dependency that references aws-sdk. The lambda environment provides aws-sdk for you so I don't want to bundle it (it adds about 6MB to the package size), but I can't exclude it.

I'm using workspaces so I have:

/package.json
  - dependencies:
    - aws-sdk
/lambda-workspace-a/package.json
  - dependencies:
    - external-module-depends-on-aws-sdk
/lambda-workspace-b/package.json

When I build my lambda environment, only my /lambda-workspace-a/package.json and lambda-workspace-b/package.json files are installed in order to package up the lambdas individually. This is great because my "provided" dependencies are in /package.json and my "runtime" dependencies are in the workspaces themselves.

But since external-module-depends-on-aws-sdk is also a runtime dependency and includes aws-sdk, it's forcing me to to include aws-sdk in my lambda package.

Was this page helpful?
0 / 5 - 0 ratings