How do I override nested dependencies with `yarn`?

If my package has these dependencies

{ "name": "my-package",
  "dependencies": { "foobar":"~1.0.3", "baz":"2.0.9" }

And the foobar package has these dependencies

{ "name": "foobar",
  "dependencies": { "baz":"^2.0.0" }

and the most recently released version of baz is 2.1.0, the first run of yarn will install [email protected] in foobar/node_modules.

How do I force yarn to use the [email protected] package for foobar?

My understanding is that this would be possible using npm shrinkwrap (a la this question).

The summary of my question probably is: Yarn creates repeatable, deterministic installations, but how do I customize that installation?

Solution 1:

If you do in fact have a sub-dependency that is overly restrictive in what versions it will accept, you can override them using yarn.

UPDATED EDIT: Yarn now, as of 1.0, officially supports the "resolutions" block. So the way to override resolutions is to just add a block like this to package.json:

"resolutions": {
      "package-a": "2.0.0",
      "package-b": "5.0.0",
      "package-c": "1.5.2"
}

You'll get warnings for "incompatible" versions sometimes, but I find that some packages (like socket.io) are overly restrictive in what version they accept, and so I'll happily select the latest version when it doesn't actually break things.

Original but outdated answer below.

It sounds like the original question wasn't exactly correct, but the original question was in fact the one I wanted answered, and I found an answer, so here it is for posterity:

I'm using the socket.io library, and it has component-emitter as a dependency. But it has a pair of versions that it requires. This is what the yarn.lock file looked like before I changed anything:

[email protected]:
  version "1.1.2"
  resolved "https://registry.yarnpkg.com/component-emitter/-/component-emitter-1.1.2.tgz#296594f2753daa63996d2af08d15a95116c9aec3"

[email protected]:
  version "1.2.0"
  resolved "https://registry.yarnpkg.com/component-emitter/-/component-emitter-1.2.0.tgz#ccd113a86388d06482d03de3fc7df98526ba8efe"

So it was including two copies of the component emitter in my client code. I looked, and there didn't appear to be any breaking changes between 1.1.2 and 1.2.0 (or 1.2.1, which was current). I first tried just changing the yarn.lock file:

[email protected], component-emitter@^1.2.1, [email protected]:
  version "1.2.1"
  resolved "https://registry.yarnpkg.com/component-emitter/-/component-emitter-1.2.1.tgz#137918d6d78283f7df7a6b7c5a63e140e69425e6"

This worked, but the file has warnings about it being autogenerated, meaning that every single update or new package I add will stomp on this change. A bit of searching found the yarn --flat option, which will force yarn to choose no more than one of each package in the entire project. That seems like overkill to me, since I'm sure there are actual cases of incompatibility between older and newer packages. I just wanted to eliminate a redundant package from my client code, to make the download smaller; I still want the development packages to all work correctly.

But in the docs to yarn --flat I found a reference to a "resolutions" block that can go in package.json:

"resolutions": {
  "package-a": "2.0.0",
  "package-b": "5.0.0",
  "package-c": "1.5.2"
}

So I tried putting "component-emitter" : "1.2.1" in a new "resolutions" block in my package.json, and it in fact flattened component-emitter to 1.2.1 for all places that required it, and now I have only one copy in my client code.

(And now the resolutions block is completely supported in yarn, so you don't even need to use --flat.)

Solution 2:

This is now possible with yarn's selective version resolution feature.

In your project's package.json, use resolutions:

  "resolutions": {
    "foobar/**/baz": "2.0.9"
  }

This overrides package foobar's (and any other packages under it) version of baz, forcing it to be version 2.0.9.

Solution 3:

EDIT: This is now deprecated, please read this answer instead:

https://stackoverflow.com/a/46615878/2398593

@SomeCallMeTime's answer is great and we've been doing that for month at work.

Unfortunately, this is not possible anymore since the v0.24.x (see that comment).

There's an opened PR on Github with an RFC proposal to have a simple way of handling that use case without having to keep an eye on the generated lockfile.