Package overrides

[aeschright]

No description provided.

[ljharb]

What if i want to override one package with another - like underscore for lodash, etc?

It would be ideal if the RHS of this could also be a full npm install argument - ie, package name/url + @ + version.

[zkat]

You would use package aliases, which are coming soon, so: "undescore": "npm:lodash"

[ljharb]

Awesome! How soon?

[zkat]

the same soon as overrides

[markcellus]

In some situations, allowing more than one version of a package to be installed at the same time can cause unwanted behaviors. This will allow users to fix that by explicitly setting a single version to use.

Wouldn't locking the dep at a certain version and running npm depupe with a package-lock.json file work for these cases?

This proposal seems similar to the resolutions field that yarn uses when having to manually resolve dependencies, which I've used. But I've found that, in practice ,these types of overrides can become easily forgotten about since it gives us another thing to manage.

But a bigger concern I have is that this seems like a solution for a symptom of the problem but doesn't attack the real problem. The real problem is that there's currently no reliable way for package maintainers to actually mark that their package should only have a single version in a consumer's dep tree. Once that is solved, I think npm can enforce it when a consumer attempts to install it and give the consumer an option on how to handle the mismatched versions, using npm dedupe or similar.

[zkat]

@mkay581 Overrides is solving a different problem! We do have a Singleton Package RFC for the "larger" problem you mention -- but overrides can be used for things like updating deep dependencies with security-patched forks, or different versions with important patches (or preventing a semver update from updating to a broken version). These are some of the examples, but ultimately, this is orthogonal to singletons, which will benefit from this, but this is not the primary purpose at all.