Yarn: Using resolutions inside a workspace inner package doesn't work

[AvivRubys]

Do you want to request a feature or report a bug?
A bug.

What is the current behavior?
When using a resolutions property in an inner package on a dependency that gets hoisted up, the resolutions property is ignored. If moved to the root package, it resolves correctly.

If the current behavior is a bug, please provide the steps to reproduce.
I've prepared an example repo with two branches - resolution-in-root and resolution-in-same-package that demonstrate this.
Simply checkout a branch, run yarn, and check the installed version of webpack. (Delete node_modules when moving between branches)
You'll see that on the resolution-in-root branch, the installed version of webpack is 3.8.1 as specified in the resolutions block, as opposed to the resolution-in-same-package where the webpack version will not be constrained by resolutions.

What is the expected behavior?
I would expect that if a dependency and a resolutions property that constrain it are in the same package.json, that the resolutions limitations will apply to the package, no matter where it gets hoisted to.

Please mention your node.js, yarn and operating system version.

$ node --version
v8.9.1

$ yarn --version
1.3.2

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.13.1
BuildVersion:   17B1003

[dvsekhvalnov]

+1 still an issue in latest 1.7.0

[jirutka]

Sigh, this is currently blocker for me, so I have to hack it somehow. :(

[buschtoens]

@jirutka you can set the resolutions in the workspace root package.json.

[arcanis]

@buschtoens is right - and while it looks simple in appearance, supporting nested resolutions in the way you expect isn't trivial. In the Yarn model, a same range always resolve to the exact same version, regardless of where they are on the dependency tree.

Due to this behavior, any custom resolution defined in a workspace would also apply on other workspaces, which would be counterintuitive. For this reason, the resolutions field is ignored in nested workspaces, and we instead force you to explicitly list them all in the root package.json.

[jirutka]

you can set the resolutions in the workspace root package.json.

No, I've tried that, it doesn't work, resolution is just ignored.

[buschtoens]

@arcanis

In the Yarn model, a same range always resolve to the exact same version, regardless of where they are on the dependency tree.

Makes total sense and I can keep working with that model. But seeing that there is a nohoist config, in wishful thinking I would intuitively have expected workspace-local resolutions to cause these dependencies to not be hoisted and also override any potential matching workspace-global resolutions.

@jirutka

No, I've tried that, it doesn't work, resolution is just ignored.

What version of yarn are you on?

There's also a nasty bug with resolutions and yarn add: when you yarn add a dependency, yarn will complain about invalid lockfile entries an will then proceed to install all dependencies, as if there were no resolutions, even if they have beem correctly resolved before.

To fix this, it's usually enough to nuke the root node_modules directory and run yarn again. I don't know if this is a known issue, but a quic search did not bring it up yet, so I'll create a separate issue for this.

[arcanis]

But seeing that there is a nohoist config

Makes sense, but the nohoist option is a hack that we actively discourage people from using, only there because some packages don't play by the rules.

No package should ever rely on its hoisting. Doing it is similar to letting users walk on a rotted wood deck then suggesting them to send a complaint to their shoemakers when it finally breaks.

[jirutka]

@buschtoens What version of yarn are you on?

1.9.4

To fix this, it's usually enough to nuke the root node_modules directory and run yarn again.

I've tried that without success.

[nicolasv]

On yarn 1.12.3 I'm kind of seeing the opposite, where the root resolutions doesn't seem to be respected?

For example, in the root package.json I have:

  "resolutions": {
    "@types/react": "16.4.2"
  }

If I do yarn workspace foo add lodash (or cd packages/foo && yarn add lodash), it doesn't respect the @types/react resolution and adds a new resolution:

diff --git a/yarn.lock b/yarn.lock
index 4b9c0f908..e3f5dd91e 100644
--- a/yarn.lock
+++ b/yarn.lock
@@ -2966,12 +2966,17 @@
     "@types/history" "*"
     "@types/react" "*"

-"@types/react@*", "@types/[email protected]", "@types/react@^0.14.44":
+"@types/react@*", "@types/[email protected]":
   version "16.4.2"
   resolved "https://registry.yarnpkg.com/@types/react/-/react-16.4.2.tgz#f1a9cf1ee85221530def2ac26aee20f910a9dac8"
   dependencies:
     csstype "^2.2.0"

+"@types/react@^0.14.44":
+  version "0.14.57"
+  resolved "https://registry.yarnpkg.com/@types/react/-/react-0.14.57.tgz#1878a8654fafdd1d381b8457292b6433498c5b62"
+  integrity sha1-GHioZU+v3R04G4RXKStkM0mMW2I=
+
 "@types/redis@*", "@types/redis@^2.8.6":
   version "2.8.6"
   resolved "https://registry.yarnpkg.com/@types/redis/-/redis-2.8.6.tgz#3674d07a13ad76bccda4c37dc3909e4e95757e7e"

However, if I copy the root package.json's resolutions to foo/package.json then it respects the resolution when I do yarn workspace foo add lodash.

I'm not sure if this is intended behaviour or not.

[Jessidhia]

It seems that yarn add (and yarn upgrade, yarn upgrade-interactive, with or without --latest) do not respect resolutions, and create an already-stale yarn.lock. (yarn upgrade-interactive --latest is even incapable of upgrading resolution dependencies, even if you can pick them in the interactive menu). Re-running yarn install will re-resolve the packages again, this time according to resolutions.

[gitowiec]

I have the same problem. I just can't override @types/react with

  "resolutions": {
    "**/@types/react": "16.8.5"
  },

using yarn 1.13.0.
I have huge conflict of types in my monorepo and I don't know how to resolve it. Putting this with TypeScript config and Webpack config, I am really going gray... :(
I see OP added this issue over a year ago. It's wrong that it is still not fixed.

[arcanis]

You wouldn't imagine the number of priorities that people think I should have 🙂

Yarn v2 will completely overhaul the resolution logic and will solve many shortcomings we have with the current one - afaik this particular issue is already fixed there.

[HosseinAgha]

God this is so annoying 😭. And it is not mostly the yarn's fault. The package developers (even famous packages) does not respect semantic versioning in so many instances and this creates a huge mess.

[AndreLacasse]

Still happens to me with the version 1.21.1 and looks to be fixed with the last version 1.22.4. The issue is still open?