Using resolutions inside a workspace inner package doesn't work #5039

AvivRubys · 2017-12-05T14:51:46Z

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

The text was updated successfully, but these errors were encountered:

dvsekhvalnov · 2018-06-08T18:29:02Z

+1 still an issue in latest 1.7.0

jirutka · 2018-08-28T13:24:40Z

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

buschtoens · 2018-08-28T15:42:21Z

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

arcanis · 2018-08-28T15:59:06Z

@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 · 2018-08-28T16:19:23Z

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 · 2018-08-28T16:53:00Z

@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 been 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 quick search did not bring it up yet, so I'll create a separate issue for this.

arcanis · 2018-08-28T17:04:10Z

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 · 2018-08-28T17:10:26Z

@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.

@rmevans9

A few issues fixed here in the `typescript` theme... ### GraphQL When i brought in apollo, it upped the graphql version to 14. This was incompatible with `graphql` and `@types/graphql` 13 which was being used by `type-graphql`. Fortunately, @rmevans9 is a wizard and showed me how to fix via `yarn resolutions`. There's currently an [yarn issue](yarnpkg/yarn#5039) that requires me to put the `resolutions` in both `package.json` and `packages/reactotron-server/package.json`, but no big deal. ### tslint I brought in `ts-lint` for `reactotron-server`. ### typescript I bumped the version to `3.0.3` cuz there's some footguns in prior versions. ### tsconfig out dir changes When you `tsc` a folder that has 2 directories, both directories are copied to the `outDir`. 1 directory will only copy the contents (strangely enough). So I updated the `outDir` to reflect that. Sorry about that. That caught me off guard. ### .gitignore I promoted the `.cache` to the root `.gitignore`. This is for `parcel`, but having 1 `.gitignore` is preferable since `vscode` doesn't seem to support unioning them together nicely (to make the folders dim in the explorer view).

nvenegas · 2018-12-13T03:21:04Z

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/react@16.4.2", "@types/react@^0.14.44":
+"@types/react@*", "@types/react@16.4.2":
   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 · 2019-02-22T03:44:22Z

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 · 2019-02-26T17:14:33Z

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 · 2019-03-14T08:38:31Z

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 · 2019-10-28T13:41:27Z

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 · 2020-03-12T14:57:22Z

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?

Yarn dependency resolutions seem not be fully compatible with Yarn workspaces, see yarnpkg/yarn#5039. Considering these lines didn’t have any effect for a while now, it’s arguably safer to remove them than to move them to the root package.json.

After moving to the monorepo and adding angular there was a version conflict for @storybook/theming and @emotion/core that prevented the 'Show Info' button from working on React. I set resolutions for the react package in the root package.json, because yarn will ignore resolutions in workspace packges in monorepos. See: yarnpkg/yarn#5039

Looks like we were running into a variant of: yarnpkg/yarn#5039 My "resolutions" weren't having the expected effect (we were getting both 2.4.0 and 2.2.6 of "metal-uri"), even after deleting the yarn.lock and recreating it. So here, I add an empty "workspaces" config, like the other projects under "maintenance" have (well, technically, they all have non-empty "workspaces" config) and that makes it work. Now we only have 2.2.6 in the lockfile! Note that because I deleted the lockfile before preparing this commit, it also includes some innocuous updates. The build still works.

anatol-grabowski · 2021-05-06T19:15:00Z

Still happens to me on 1.22.4 and 1.22.10.
Moving resolutions to the root package.json (kind of) solves the issue.
I also expect "workspace-local resolutions to cause these dependencies to not be hoisted and also override any potential matching workspace-global resolutions."

olee · 2021-07-14T15:44:13Z

I have the same issue even with yarn 2 :-/

merceyz · 2021-07-14T19:54:39Z

I have the same issue even with yarn 2 :-/

@olee yarn@>=2 only supports resolutions in the project root

asvetly · 2021-10-03T08:47:32Z

still actual with yarn@3.0.2

Jest before v27 didn't support configuration options that allow test files to be discovered across symlink boundaries, which is necessary when running Jest tests within a Bazel sandbox. Upgrade Jest and its dependencies (including a manual version resolution of jest-environment-jsdom [1] defined in pkg/ui/package.json to avoid Jest bugs [2]) to enable cluster-ui tests being run via Bazel. [1] enzymejs/enzyme-matchers#351 (comment) [2] yarnpkg/yarn#5039 Release justification: Upgrade of test dependencies Release note: None

jhowell-droit · 2023-02-21T17:51:42Z

Still seems to be an issue in v3.4.1. If anyone knows how to get it working in this version I'd love to know!

tommymarshall · 2023-06-27T19:55:46Z

Still an issue :( This is coming up more with our NextJS app expecting one version and a package with a hard dependency expecting another.

KostyaTretyak · 2023-08-18T14:57:50Z

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.

@arcanis, I wonder why you don't even issue warning logs in this case?

arcanis · 2023-08-18T15:50:01Z

We do, in all modern releases (ie >=2).

zargold · 2023-09-08T18:33:26Z

arcanis commented 3 weeks ago
We do, in all modern releases (ie >=2).

These 2 messages are in conflict:

jhowell-droit commented on Feb 21
Still seems to be an issue in v3.4.1. If anyone knows how to get it working in this version I'd love to know!

I am also having this issue where I need to specify resolutions at the base package.json with:

yarn --version
3.2.2

arcanis · 2023-09-09T06:00:51Z

The message I'm answering to is:

I wonder why you don't even issue warning logs in this case

Modern releases don't support the resolutions setting anywhere else than the root, and we generate a warning when you accidentally do it.

I think I'm going to lock this thread, there isn't more to say around this topic on this repo.

ghost assigned arcanis Dec 5, 2017

ghost added the triaged label Dec 5, 2017

AvivRubys changed the title ~~Resolutions inside a workspace package doesn't work~~ Using resolutions inside a workspace inner package doesn't work Dec 5, 2017

skellock mentioned this issue Sep 7, 2018

🐛 TypeScript Fixtravaganza infinitered/reactotron#812

Merged

This was referenced Jun 25, 2019

WIP: markdown to custom components Royal-Navy/design-system#90

Closed

WIP: Feature/EN-688 markdown to custom component Royal-Navy/design-system#93

Closed

kevinsperrine mentioned this issue Apr 7, 2021

fix(storybook): fix 'show info' button carbon-design-system/carbon-addons-iot-react#2202

Merged

ryanio mentioned this issue Aug 4, 2021

ci: fix hardhat e2e resolutions ethereumjs/ethereumjs-monorepo#1391

Merged

kevinsperrine mentioned this issue Aug 11, 2021

fix(repo): pin @carbon/charts versions carbon-design-system/carbon-addons-iot-react#2651

Merged

9 tasks

abdonrd mentioned this issue Nov 6, 2021

chore(lit): update lit dependencies carbon-design-system/carbon-for-ibm-dotcom#7603

Closed

m1aw mentioned this issue Mar 8, 2022

Fixes CSP error caused by regenerator-runtime Adyen/adyen-web#1528

Merged

wlee221 mentioned this issue Aug 15, 2022

chore(ui-react-native): Add storybook aws-amplify/amplify-ui#2464

Merged

5 tasks

christiannaths mentioned this issue Sep 16, 2022

Admin UI continually compiling keystonejs/keystone#7902

Closed

pencilcheck mentioned this issue Nov 30, 2022

installModule doesn't work with nuxt 2 modules nuxt/nuxt#15507

Closed

yarnpkg locked and limited conversation to collaborators Sep 9, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Using resolutions inside a workspace inner package doesn't work #5039

Using resolutions inside a workspace inner package doesn't work #5039

AvivRubys commented Dec 5, 2017

dvsekhvalnov commented Jun 8, 2018

jirutka commented Aug 28, 2018

buschtoens commented Aug 28, 2018

arcanis commented Aug 28, 2018

jirutka commented Aug 28, 2018

buschtoens commented Aug 28, 2018 •

edited

Loading

arcanis commented Aug 28, 2018

jirutka commented Aug 28, 2018

nvenegas commented Dec 13, 2018 •

edited

Loading

Jessidhia commented Feb 22, 2019 •

edited

Loading

gitowiec commented Feb 26, 2019 •

edited

Loading

arcanis commented Mar 14, 2019 •

edited

Loading

HosseinAgha commented Oct 28, 2019 •

edited

Loading

AndreLacasse commented Mar 12, 2020

anatol-grabowski commented May 6, 2021

olee commented Jul 14, 2021

merceyz commented Jul 14, 2021

asvetly commented Oct 3, 2021

jhowell-droit commented Feb 21, 2023

tommymarshall commented Jun 27, 2023

KostyaTretyak commented Aug 18, 2023

arcanis commented Aug 18, 2023

zargold commented Sep 8, 2023 •

edited

Loading

arcanis commented Sep 9, 2023

Using resolutions inside a workspace inner package doesn't work #5039

Using resolutions inside a workspace inner package doesn't work #5039

Comments

AvivRubys commented Dec 5, 2017

dvsekhvalnov commented Jun 8, 2018

jirutka commented Aug 28, 2018

buschtoens commented Aug 28, 2018

arcanis commented Aug 28, 2018

jirutka commented Aug 28, 2018

buschtoens commented Aug 28, 2018 • edited Loading

arcanis commented Aug 28, 2018

jirutka commented Aug 28, 2018

nvenegas commented Dec 13, 2018 • edited Loading

Jessidhia commented Feb 22, 2019 • edited Loading

gitowiec commented Feb 26, 2019 • edited Loading

arcanis commented Mar 14, 2019 • edited Loading

HosseinAgha commented Oct 28, 2019 • edited Loading

AndreLacasse commented Mar 12, 2020

anatol-grabowski commented May 6, 2021

olee commented Jul 14, 2021

merceyz commented Jul 14, 2021

asvetly commented Oct 3, 2021

jhowell-droit commented Feb 21, 2023

tommymarshall commented Jun 27, 2023

KostyaTretyak commented Aug 18, 2023

arcanis commented Aug 18, 2023

zargold commented Sep 8, 2023 • edited Loading

arcanis commented Sep 9, 2023

buschtoens commented Aug 28, 2018 •

edited

Loading

nvenegas commented Dec 13, 2018 •

edited

Loading

Jessidhia commented Feb 22, 2019 •

edited

Loading

gitowiec commented Feb 26, 2019 •

edited

Loading

arcanis commented Mar 14, 2019 •

edited

Loading

HosseinAgha commented Oct 28, 2019 •

edited

Loading

zargold commented Sep 8, 2023 •

edited

Loading