resolutions doesn't work with deps that have '/' in their name

[burabure]

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

What is the current behavior?
Resolutions for packages that use namespacing aren't respected.
example:

  "resolutions": {
    "@types/storybook__react/@types/react": "16.0.20"
  },

resulting yarn.lock still declares an older version of @types/react for @types/storybook__react

Please mention your node.js, yarn and operating system version.
node: v6.9.1
yarn: 1.3.2
Ubuntu 16.04.3 LTS

[andrekovac]

Any progress on this one? I'm facing the same issue.

Resolutions with an @ do not seem to work.
The following doesn't work for me:

    "resolutions": {
        "@storybook/**/ts-loader": "3.5.0"
    },

EDIT: I just realized that @storybook does not have the ts-loader dependency as such. I'm just using ts-config in my custom webpack.config for storybook. So I believe this will not work with resolutions, am I right?

---

Versions:
node: 8.10.0
yarn: 1.9.4
Ubuntu 18.04.1 LTS

[SuhairZain]

@arcanis Hi, is there any progress on this? I'm facing a similar issue with a nested dependency.

[andrewkfiedler]

@burabure (or anyone else) did you happen to find a work around for this?

I'm debating republishing the package with without a slash to get around this.

Edit: I was able to find some work being done around selective resolutions: #4243

[andrewkfiedler]

It's possible I'm misunderstanding how to utilize these.

My current setup is I have a root workspace with these children inside:
Project A package.json (which is the source of the issue):

   dependencies: {
      backbone.marionette: '2.4.1'
   }

Project B package.json (which is the application having issues):

   dependencies: {
         backbone.marionette: '1.8.8',
         @organization/UILibrary: '0.0.22'
   }

The @organization/UILibrary (which is outside the workspace) package.json looks like so:

      peerDependencies: {
           backbone.marionette: ">= 1 < 3"
      }

Unfortunately, even though Project B has no dependency on Project A, when @organization/UILibrary is pulled into Project B it gets backbone.marionette version 2.4.1 for it's requires (whereas the requires local to Project B get 1.8.8).

My attempt to use resolutions is updating Project B package.json to this:

   dependencies: {
         backbone.marionette: '1.8.8',
         @organization/UILibrary: '0.0.22'
},
{
"resolutions": {
    "@organization/**/backbone.marionette": "1.8.8",
    "@organization/backbone.marionette": "1.8.8",
    "@organization/UILibrary/backbone.marionette: "1.8.8",
    "@organization/UILibrary/**/backbone.marionette: '1.8.8"
  }
}

Any ideas? I can add more details if people need them, and if desired I can open a different issue (sorry if I'm hijacking this one, but it seemed relevant).

[aruniverse]

It's 2020, is there any update on this? Seems like an edge-case that should've been covered.

I'm running into an issue with a type definition package, and trying to do something like this:

  "resolutions": {
    "@types/PackageA/**/@types/PackageB": "x.y.z"
  },

I was hoping to use yarn resolutions and not have to use declaration merging.

[walkerburgin]

I think I was able to get this to work by specifying the resolution like this:

  "resolutions": {
    "**/@types/PackageA/**/@types/PackageB": "x.y.z"
  },

[stevemarksd]

That's a huge issue, @types/react can't be installed properly

[Kingwl]

Sorry for the bother, but I think I may still need to ping again.

It's important for those who need to use resolutions.

[Kingwl]

I'm happy to work on this. But I'm not familiar enough to the codebase.

@arcanis Would you mind give some suggestions?

[ArtyomResh]

@arcanis Sorry, but I think I need to ping it too. Is there any progress on this? I'm too not familiar enough to the codebase, but how could I help?

[keewe-tech]

Up 😕

[arcanis]

Afaik this got fixed in all of the Yarn 2+ releases.

[aggarwalShivani]

I am facing a similar issue - package @storybook/ui has a dependency on @types/markdown-to-jsx and I intend to use higher version of @types/markdown-to-jsx using resolutions.
"**/@storybook/ui/@types/markdown-to-jsx" : "^6.11.4" but it fails with error Couldn't find any versions for "@types/markdown-to-jsx" that matches "^6.11.4"

In which version of yarn is this resolved? Also, can someone suggest a workaround to achieve this?

Versions used:
yarn: 1.22.10
node: v10.23.1

[sarahbethfederman]

Any chance the fix could get backported to yarn 1? Upgrading to yarn 2 is not feasible for a lot of people

[arcanis]

Any chance the fix could get backported to yarn 1? Upgrading to yarn 2 is not feasible for a lot of people

No, we don't do backport over two majors (the last release is currently 3.0). However I suspect the migration should be fairly simple if you follow our step-by-step guide. If not, post where you're blocked on our Discord and we'll try to help.

Edit 2022/01/26: Oh hey, visitors from Twitter. Turns out Adam is essentially talking shit and has no idea about adoption, compatibility, feature set, outside of what he sees his Twitter feed. Seriously, tech twitter bros are so embarrassing.

[squarewave24]

Edit 2022/01/26: Oh hey, visitors from Twitter. Turns out Adam is essentially talking shit and has no idea about adoption, compatibility, feature set, outside of what he sees his Twitter feed. Seriously, tech twitter bros are so embarrassing.

i tried upgrading to 2 and 3 and have been in a world of pain. like.. yarn install doesn't work for me at all in 2 (getting "cannot apply hunk" errors), and it was throwing random error when lock file was removed (i had to touch yarn.lock to fix this after some googling).. yarn 3 starting is complaining about webpack / react-scripts incompatibilities (same setup works fine in yarn 1). i don't think the solution is to call users clueless and point to "step by step" instructions that may or may not work 💔

[lobsterkatie]

Any chance the fix could get backported to yarn 1? Upgrading to yarn 2 is not feasible for a lot of people

No, we don't do backport over two majors (the last release is currently 3.0). However I suspect the migration should be fairly simple if you follow our step-by-step guide. If not, post where you're blocked on our Discord and we'll try to help.

Did this get backported in the end, though? I am using yarn 1 and it seems to work fine for me.

Set up:

Yarn 1.22.19
Monorepo using yarn workspaces
Some (but not all) packages have a @types/express dev dependency.
@types/express depends on @types/express-serve-static-core, which just pushed a breaking update

packages/pkgA/package.json

devDependencies: {
  "@types/express": "^4.17.14"
}

packages/pkgB/package.json

devDependencies: {
  "@types/express": "^4.17.14"
}

package.json

devDependencies: {
  // no `@types/express`
},
resolutions: {
  "@types/express-serve-static-core": "4.17.30"
}

Works like a charm, even though the discussion here leads me to believe that it shouldn't be.

Output of yarn why @types/express-serve-static-core:

> yarn why @types/express-serve-static-core
yarn why v1.22.19
[1/4] 🤔  Why do we have the module "@types/express-serve-static-core"...?
[2/4] 🚚  Initialising dependency graph...
warning Resolution field "@types/[email protected]" is incompatible with requested version "@types/[email protected]"
[3/4] 🔍  Finding dependency...
[4/4] 🚡  Calculating file sizes...
=> Found "@types/[email protected]"
info Reasons this module exists
   - "_project_#@types#express" depends on it
   - Hoisted from "_project_#@types#express#@types#express-serve-static-core"
   - Hoisted from "_project_#@sentry-internal#node-integration-tests#apollo-server#apollo-server-express#@types#express-serve-static-core"
   - Hoisted from "_project_#@sentry-internal#node-integration-tests#apollo-server#apollo-server-express#@types#express#@types#express-serve-static-core"
info Disk size without dependencies: "1.84MB"
info Disk size with unique dependencies: "2.59MB"
info Disk size with transitive dependencies: "2.59MB"
info Number of shared dependencies: 3