Failed to install dependencies in workspace: expected workspace package to exist

Question

Failed to install dependencies in workspace: expected workspace package to exist

zamotany opened this issue 5 years ago · comments

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

What is the current behavior?
yarn install fails with:

error An unexpected error occurred: "expected workspace package to exist for \"@babel/template\"".

The error started occurring after upgrading yarn to 1.19 and it still persists in latest stable version 1.21.1

Similar errors can be observed in #7797 and #7734

If the current behavior is a bug, please provide the steps to reproduce.
The error can be reproduced when installing dependencies in https://github.com/callstack/haul

git clone git@github.com:callstack/haul.git
cd haul
yarn install

What is the expected behavior?

yarn install should successfully install dependencies.

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

Node: 12.14.1 / 13 (reproducible on both)
yarn: 1.21.1
OS: macOS 10.15.2

Sam Rose · Answer 1 · Tue Jan 14 2020 20:17:28 GMT+0800 (China Standard Time)

Experiencing the same behavior when trying to add a dependency to a workspace package:

yarn workspace @scope/mypackage add npm-package

error An unexpected error occurred: "expected workspace package to exist for \"@babel/highlight\"".

Similar details

Yarn version: 
  1.21.1

Node version: 
  10.17.0

Platform: 
  darwin x64

OS
  macOS 10.15.2

Klaas Landsman · Answer 2 · Wed Jan 15 2020 17:51:31 GMT+0800 (China Standard Time)

Experiencing the same issue with node@10:

An unexpected error occurred: "expected workspace package to exist for \"lru-cache\"".

Node: 10.15.3
yarn: 1.21.1
OS: macOS 10.15.1

I found a (temporary) workaround by running the policies feature of yarn in my repo:

> yarn policies set-version 1.18.0

which basically means:

Under the hood, the command will simply download the single-file release from the GitHub repository, store it inside your project (inside the .yarn/releases folder), then finally update your configuration to point to the new file (using yarn-path).

Andrew Schmadel · Answer 3 · Wed Jan 15 2020 23:09:03 GMT+0800 (China Standard Time)

Also seeing this in Yarn 1.21.1. I can reproduce the error in my repository when running yarn upgrade-interactive, but manually bumping versions in package.json still works fine for some reason.

Olivier Louvignes · Answer 4 · Mon Jan 27 2020 23:56:27 GMT+0800 (China Standard Time)

Encountering this as well:

error An unexpected error occurred: "expected workspace package to exist for \"string-length\"".

When trying to add an unrelated dependency inside one on my workspace packages yarn add @reduxjs/toolkit. Manually adding the dep to package.json followed by a yarn does work.

Tried yarn cache clean, and did delete both yarn.lock & node_modules folders, no change.

▶ yarn --version
1.21.1

Nestor Felipe (nefe) · Answer 5 · Tue Jan 28 2020 17:26:22 GMT+0800 (China Standard Time)

Same error here:

$ yarn workspace @scope/web add ramda
error An unexpected error occurred: "expected workspace package to exist for \"chalk\"".
info If you think this is a bug, please open a bug report with the information provided in "/home/user/projects/web/apps/web/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.
error Command failed.
Exit code: 1

Adding yarn-error.log

Arguments: 
  /home/user/.nvm/versions/node/v10.13.0/bin/node /home/user/.nvm/versions/node/v10.13.0/lib/node_modules/yarn/lib/cli.js add ramda

PATH: 
  /home/user/.yarn/bin:/home/user/.config/yarn/global/node_modules/.bin:/home/user/.yarn/bin:/home/user/.config/yarn/global/node_modules/.bin:/home/user/.nvm/versions/node/v10.13.0/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/user/Android/Sdk/emulator:/home/user/Android/Sdk/tools:/home/user/Android/Sdk/tools/bin:/home/user/Android/Sdk/platform-tools:/home/user/Android/Sdk/emulator:/home/user/Android/Sdk/tools:/home/user/Android/Sdk/tools/bin:/home/user/Android/Sdk/platform-tools

Yarn version: 
  1.21.1

Node version: 
  10.13.0

Platform: 
  linux x64

Trace: 
  Invariant Violation: expected workspace package to exist for "chalk"
      at invariant (/home/user/.nvm/versions/node/v10.13.0/lib/node_modules/yarn/lib/cli.js:2314:15)
      at _loop2 (/home/user/.nvm/versions/node/v10.13.0/lib/node_modules/yarn/lib/cli.js:94898:9)
      at PackageHoister.init (/home/user/.nvm/versions/node/v10.13.0/lib/node_modules/yarn/lib/cli.js:94957:19)
      at PackageLinker.getFlatHoistedTree (/home/user/.nvm/versions/node/v10.13.0/lib/node_modules/yarn/lib/cli.js:48743:20)
      at PackageLinker.<anonymous> (/home/user/.nvm/versions/node/v10.13.0/lib/node_modules/yarn/lib/cli.js:48754:27)
      at Generator.next (<anonymous>)
      at step (/home/user/.nvm/versions/node/v10.13.0/lib/node_modules/yarn/lib/cli.js:310:30)
      at /home/user/.nvm/versions/node/v10.13.0/lib/node_modules/yarn/lib/cli.js:328:14
      at new Promise (<anonymous>)
      at new F (/home/user/.nvm/versions/node/v10.13.0/lib/node_modules/yarn/lib/cli.js:5301:28)

npm manifest: 
{
   ...
}

Tommaso Ferrari · Answer 6 · Thu Feb 06 2020 04:16:08 GMT+0800 (China Standard Time)

I have been experiencing the same issues since v1.19.
yarn upgrade-interactive became unusable; It would fail to apply the version updates.

After updating to v1.21 I'm not able to yarn install anymore. It always throws this error:

expected workspace package to exist for ...

Downgrading to 1.18 fixed both issues.

I should point out that these problems only occur on one project, which is a monorepo that uses lerna and yarn workspaces.

Jacob · Answer 7 · Tue Feb 11 2020 04:18:24 GMT+0800 (China Standard Time)

Same experience as @raspo
Can't install packages from the command line anymore in my workspace enabled monorepo.

Ricky · Answer 8 · Tue Feb 11 2020 19:48:59 GMT+0800 (China Standard Time)

I didn't want to have to downgrade yarn since it comes from my package manager so I used npx as a terrible workaround.

npx yarn@1.19.0 add your-deps-here

Harley Alexander · Answer 9 · Thu Feb 13 2020 03:22:00 GMT+0800 (China Standard Time)

Also get this 1.17 through 1.22. It seems to be a handful of packages - starting with istanbul-lib-instrument. Then jest-snapshot then cssstyle repeatedly.

Invariant Violation: expected workspace package to exist for "istanbul-lib-instrument"
    at invariant (/usr/local/Cellar/yarn/1.22.0/libexec/lib/cli.js:2314:15)
    at _loop2 (/usr/local/Cellar/yarn/1.22.0/libexec/lib/cli.js:94959:9)
    at PackageHoister.init (/usr/local/Cellar/yarn/1.22.0/libexec/lib/cli.js:95018:19)
    at PackageLinker.getFlatHoistedTree (/usr/local/Cellar/yarn/1.22.0/libexec/lib/cli.js:48743:20)
    at PackageLinker.<anonymous> (/usr/local/Cellar/yarn/1.22.0/libexec/lib/cli.js:48754:27)
    at Generator.next (<anonymous>)
    at step (/usr/local/Cellar/yarn/1.22.0/libexec/lib/cli.js:310:30)
    at /usr/local/Cellar/yarn/1.22.0/libexec/lib/cli.js:328:14
    at new Promise (<anonymous>)
    at new F (/usr/local/Cellar/yarn/1.22.0/libexec/lib/cli.js:5301:28)

lerna.json

{
  "packages": [
    "packages/*",
    "apps/*"
  ],
  "version": "1.0.17",
  "npmClient": "yarn",
  "useWorkspaces": true
}

package.json:

{
...
"workspaces": {
    "packages": [
      "apps/*",
      "packages/*"
    ],
    "nohoist": [
      "**/webpack-dev-server"
    ]
  },
...
}

Petros Kyriakou · Answer 10 · Mon Feb 17 2020 18:29:17 GMT+0800 (China Standard Time)

I am also getting this regression any news?

Roman Ožana · Answer 11 · Tue Feb 18 2020 16:11:34 GMT+0800 (China Standard Time)

same here, monorepo and yarn interactive upgrade on mac

Invariant Violation: expected workspace package to exist for "stack-utils"
    at invariant (/usr/local/Cellar/yarn/1.22.0/libexec/lib/cli.js:2314:15)
    at _loop2 (/usr/local/Cellar/yarn/1.22.0/libexec/lib/cli.js:94959:9)
    at PackageHoister.init (/usr/local/Cellar/yarn/1.22.0/libexec/lib/cli.js:95018:19)
    at PackageLinker.getFlatHoistedTree (/usr/local/Cellar/yarn/1.22.0/libexec/lib/cli.js:48743:20)
    at PackageLinker.<anonymous> (/usr/local/Cellar/yarn/1.22.0/libexec/lib/cli.js:48754:27)
    at Generator.next (<anonymous>)
    at step (/usr/local/Cellar/yarn/1.22.0/libexec/lib/cli.js:310:30)
    at /usr/local/Cellar/yarn/1.22.0/libexec/lib/cli.js:328:14
    at new Promise (<anonymous>)
    at new F (/usr/local/Cellar/yarn/1.22.0/libexec/lib/cli.js:5301:28)

$ yarn lerna --version
3.20.2
$ yarn version
1.22.0
$ node --version
v13.8.0

Petros Kyriakou · Answer 12 · Tue Feb 18 2020 16:15:52 GMT+0800 (China Standard Time)

As a temp solution use something yvm and use version 1.18.0. Works for me

Mike James · Answer 13 · Thu Feb 20 2020 14:31:22 GMT+0800 (China Standard Time)

yarn policies set-version 1.18.0 works for me - yarn will automatically switch to this version just for the project! so neat!
https://classic.yarnpkg.com/en/docs/cli/policies/

Alessio Occhipinti · Answer 14 · Thu Mar 05 2020 00:13:50 GMT+0800 (China Standard Time)

I just had the same problem on a monorepo Lerna + Yarn (v1.22). Solved re-creating the yarn.lock.

Nathan L Smith · Answer 15 · Thu Mar 05 2020 06:24:40 GMT+0800 (China Standard Time)

This looks like a duplicate of #7734.

Matt Huggins · Answer 16 · Fri Mar 13 2020 03:39:01 GMT+0800 (China Standard Time)

Running into this for @storybook/api. @nerdyman's workaround appears to have worked for me in the interim.

xiaoTuiMao · Answer 17 · Tue Mar 24 2020 11:28:25 GMT+0800 (China Standard Time)

I didn't want to have to downgrade yarn since it comes from my package manager so I used npx as a terrible workaround.
npx yarn@1.19.0 add your-deps-here

it's work for me

Americo Savinon · Answer 18 · Tue Mar 31 2020 23:09:22 GMT+0800 (China Standard Time)

I had this same problem and although deleting yarn.lock and running yarn install (or yarn workspace some-workspace bla bla bla) worked, the problem was that I was using a newer version of yarn compare to my team members.

So the solution was to use yarn policies. You basically run yarn policies set-policy and this will download the latest stable version of yarn and save it in .yarn/ and also update your .yarnrc to point to downloaded yarn version. This way you can ensure everyone is using the same yarn version and avoid this kind of isues.

More info here: https://classic.yarnpkg.com/en/docs/cli/policies#toc-policies-set-version

Tommy D. Rossi · Answer 19 · Thu Apr 09 2020 05:10:29 GMT+0800 (China Standard Time)

So the solution to this problem is downgrading yarn, yarn 2.0 will be fun

Randall Leeds · Answer 20 · Thu Apr 09 2020 07:01:00 GMT+0800 (China Standard Time)

@remorses apologies if I incorrectly read sarcasm in your reply. I haven't seen anyone submit a PR to fix this in 1.x. It's possible that, in other issues, folks have submitted fixes for this or other bugs that have been rejected, and that would make me sad. If there are abundant PRs for 1.x that are being ignored, I would hope that the maintainers would welcome community members who want to help maintain 1.x. Without PRs and maintenance from the community, it's hard to fault anyone for wanting to focus on their active development branch.

Abdullah Musab Ceylan · Answer 21 · Mon May 04 2020 09:42:45 GMT+0800 (China Standard Time)

This usually happens if you are using a different version of the same npm package in workspaces.

Let's say you have @scope/www and @scope/api workspaces and both are have eslint npm package. But @scope/www is using eslint@6.5.1 whereas @scope/api is using eslint@5.12.1. Also, you have eslint@6.8.0 in the root packages.json.

Then if you try to install a package to one of the workspaces, you will get error An unexpected error occurred: "expected workspace package to exist for \"eslint\"". error. Because none of your eslint versions are identical.

Once you make them identical then you shouldn't get any error.

Frieder Bluemle · Answer 22 · Mon May 04 2020 12:49:54 GMT+0800 (China Standard Time)

That's interesting, thanks for the additional details @abdullahceylan - Just curious: How did Yarn before 1.19.2 (no error) handle this situation?

Abdullah Musab Ceylan · Answer 23 · Tue May 05 2020 06:17:55 GMT+0800 (China Standard Time)

It also gives the same error to me @friederbluemle

Mariah · Answer 24 · Tue May 12 2020 00:41:24 GMT+0800 (China Standard Time)

I was experiencing this issue because I had different versions of @babel/core in my workspaces, just as @abdullahceylan said. Updating @babel/core to the same version solved the problem for me! 🙏

Alexander Vansach · Answer 25 · Wed May 13 2020 15:48:49 GMT+0800 (China Standard Time)

I wish there was a more specific message for this error.

Fabian Dietenberger · Answer 26 · Wed May 20 2020 14:41:51 GMT+0800 (China Standard Time)

Also had this problem but could solve it:
The reason was that I had a package (eslint) in one of my packages and in the root workspace. Removed it from the root workspace and everything was working again.

Lennard · Answer 27 · Sun Jun 14 2020 00:01:31 GMT+0800 (China Standard Time)

Found out that my issues came from that @babel/core in nextjs was fixed on 7.7.7 and some other modules were requiring ^7.10.0 so thats why yarn puts an extra node_module folder inside your package to resolve the dependency conflicts.

I solved it use resolutions by doing

  "resolutions": {
    "**/@babel/core": "7.10.2"
  },

And did a yarn install / npx lerna bootstrap

Martin Muñoz · Answer 28 · Sat Jun 20 2020 04:46:41 GMT+0800 (China Standard Time)

In the application I am working on I was able to resolve this bug by changing

"workspaces": [
  "packages/**/*"
],

to

"workspaces": [
  "packages/@org1/*",
  "packages/@org2/*",
  "packages/*"
],

Perhaps yarn is accidentally detecting a nested workspace inside the node_modules of one of my packages? I didn't have time to look into it. I was using yarn 1.22.4.

EDIT: This seems to be corroborated by the claims that consolidating dependency versions (which in turn hoists them out of the packages directory) can also solve this problem.

Uladzimir Havenchyk · Answer 29 · Wed Jun 24 2020 03:40:45 GMT+0800 (China Standard Time)

what worked for me is

yarn lerna add npmpackage --scope=@scope/my-package

you can use npx instead of yarn here

Jason Waldrip · Answer 30 · Wed Jun 24 2020 03:42:27 GMT+0800 (China Standard Time)

Same here yarn add completely blows up on trying to do any package. Please fix 🙏

Nantris · Answer 31 · Wed Jun 24 2020 05:55:11 GMT+0800 (China Standard Time)

~~Suddenly running into this absolutely out of the blue. No idea how to remedy it.~~

Edit: I had a package local to my mono-repo with the same name as an npm dependency, as mentioned by @abdullahceylan.

Daniele De Matteo · Answer 32 · Wed Jun 24 2020 06:12:01 GMT+0800 (China Standard Time)

I had the same issue with yarn add. In my case, it was complaining for eslint. I manually set the eslint version to 7.2.0.
I went through my yarn.lock to check which dependencies were asking a different version of eslint (just used the "Find" tool with the eslint keyword).
I realized that lots of dependencies were requiring the version 6.8.0 and they were trying to install it.

I've solved the issue setting the eslint version to 6.8.0.
Either you can choose to add the resolutions parameter to your package.json file. In my case, it would have been like

"resolutions": {
  "eslint": "6.8.0"
}

Hope it can help someone.

Nathaniel · Answer 33 · Wed Jun 24 2020 06:37:14 GMT+0800 (China Standard Time)

Many thanks @dxit, that helps me 😄

Alejandro Corredor · Answer 34 · Thu Jul 09 2020 11:04:27 GMT+0800 (China Standard Time)

Has anyone been able to pinpoint what exactly causes this? Will there be a fix included in v1?

Running into the same thing on a monorepo that uses hoisting. Working around it with the npx hack for installing deps.

Kyle Holmberg · Answer 35 · Wed Jul 15 2020 09:10:10 GMT+0800 (China Standard Time)

Assuming you're using Lerna, @mmun your fix may be related to an incorrect resolution order regarding packages that rely on one another. See here for more details.

ralphilius · Answer 36 · Thu Jul 16 2020 13:52:22 GMT+0800 (China Standard Time)

I had this error with below environment:

Node: 10.20.1
Yarn: 1.22.4

It was working with below setting.

Node: 10.15.3
Yarn: 1.13.0

I've tried to set Yarn to 1.18.0 but it seemed it doesn't work with Node 10.20.1

Daniel Kempner · Answer 37 · Fri Jul 31 2020 06:39:34 GMT+0800 (China Standard Time)

Note to self: revisit this once the next version of yarn is released.

Kyle Holmberg · Answer 38 · Fri Jul 31 2020 08:12:10 GMT+0800 (China Standard Time)

@dkempner yarn 1 wont be having new versions I don't think... If they are, it's awful quiet in this repo (only 1 commit in the last 2 months). You can try with yarn@berry tho

Lucas Picchi · Answer 39 · Fri Aug 07 2020 10:18:37 GMT+0800 (China Standard Time)

After testing each release, bug starts in 1.19.2, at least for Windows. So some change between 1.19.1 - 1.19.2 breaks

Frieder Bluemle · Answer 40 · Fri Aug 07 2020 11:22:55 GMT+0800 (China Standard Time)

@thefat32 - Yup, that's correct. Not just on Windows. I have this command in my history that I use quite often as a workaround whenever I see the error:

npx yarn@1.19.1 upgrade-interactive

Isabella Martinez · Answer 41 · Thu Sep 10 2020 09:57:03 GMT+0800 (China Standard Time)

I have the same problem when add some dependecy to yarn monorepo.

error An unexpected error occurred: "expected workspace package to exist for \"jest\"".

Willemdjong · Answer 42 · Tue Sep 15 2020 17:51:52 GMT+0800 (China Standard Time)

Hi guys, I had the exact same issue!

An unexpected error occurred: "expected workspace package to exist for \"@jest-cli"".
I was experiencing this issue because I had different version of jest-cli in my workspace. Resolved it by upgrading all packages to latest version.

Julien Gonzalez · Answer 43 · Fri Sep 25 2020 21:34:04 GMT+0800 (China Standard Time)

@abdullahceylan Do you know if that's still the case though with transitive dependencies? I've the same failure as everybody else but in my case the dependency isn't mine so I don't know how I could upgrade it. And does workspaces.nohoist change anything?

Abdullah Musab Ceylan · Answer 44 · Sun Sep 27 2020 03:01:07 GMT+0800 (China Standard Time)

@customcommander TBH I haven't encountered a situation like yours but the first thing I would try in such a situation would be to use something like "**/pagkage-name" for nohoist option.

Julien Gonzalez · Answer 45 · Sun Sep 27 2020 14:09:37 GMT+0800 (China Standard Time)

Posted on Stack Overflow; just in case
Why does Yarn throw “Invariant Violation: expected workspace package to exist” when I attempt to upgrade some dependencies?

tony chen · Answer 46 · Tue Sep 29 2020 17:46:16 GMT+0800 (China Standard Time)

@customcommander TBH I haven't encountered a situation like yours but the first thing I would try in such a situation would be to use something like "**/pagkage-name" for nohoist option.

why?

Matthias von Bargen · Answer 47 · Mon Oct 05 2020 17:39:08 GMT+0800 (China Standard Time)

Currently experiencing this with lerna

kaveh · Answer 48 · Mon Oct 05 2020 22:56:31 GMT+0800 (China Standard Time)

We have narrowed this down to begin happening for us in v1.19.2

Node: v12.13.0
yarn: works <= v1.19.1
OS: macOS 10.15.6

v1.19.1...v1.19.2

yarn policies set-version 1.19.1 works for us with lerna

Victor Augusto · Answer 49 · Wed Oct 07 2020 10:17:37 GMT+0800 (China Standard Time)

Change the yarn policies to yarn policies set-version 1.18.0 worked for me too.
I was in:
Yarn: 1.22.5
Node: 10.21
OS: Arch Linux (x64)

Sylvan Mably · Answer 50 · Sun Oct 18 2020 08:58:19 GMT+0800 (China Standard Time)

I don't have a solution beyond the ones already suggested in this thread, but it seems that PR #7289 is where the regression was introduced, and specifically, these lines.

The version of this bug that I've been experiencing is especially confusing because the dependency shown in the error message was only installed in the workspace root, and not in any of the nested workspaces.

I created a minimal repro here: https://github.com/smably/yarn-workspaces-hoisting-bug. In this case, I was getting expected workspace package to exist for "pretty-quick" even though pretty-quick only appears once in the tree. The actual error seems to be happening when yarn tries to hoist the transitive dependencies of pretty-quick.

I tried poking around in the yarn codebase to see if I could fix the issue, but quite a few of the unit tests are failing on my machine, the "contributing" link in the README is broken, and I had a lot of trouble debugging because I wasn't able to get console.log or debugger statements to work (I'm guessing because yarn spawns child processes and they don't inherit node's --inspect flag). Sad to say that it seems like yarn 1 is no longer maintained by the original authors, nor is it an easy codebase for a new contributor to jump into.

日景 · Answer 51 · Wed Oct 21 2020 15:49:12 GMT+0800 (China Standard Time)

In my case, it might be the version confilcts of @babel/core. I solved it by: check out the version installed by yarn why @babel/core, add resolution to the package which is not the the same version to unify the version.

Dan · Answer 52 · Mon Oct 26 2020 00:22:49 GMT+0800 (China Standard Time)

Adding this incase someone else (god help them) has a similar issue as I've just spent half my weekend debugging / basically reformatting my computer...

I setyarn policies set-version 1.19.1 thinking everything was fine. A few hours later I did a build of my Next.js app and was getting this Error occurred prerendering page.... I literally tried everything under the sun, and have just realised that doing yarn policies set-version 1.19.1 was the cause.

What's even stranger is it destroys my local project. If I switch to a stable branch, delete all the node modules, yarn.lock etc etc, switch back to the latest version yarn, and run yarn install, then build my Next.js app again, I get the same error.

I've no idea what's going on tbh. I literally re-installed node, yarn etc. The only solution was to delete the app and clone it again.

xddz9 · Answer 53 · Wed Oct 28 2020 09:21:43 GMT+0800 (China Standard Time)

I had the same issue with eslint package. Turns out the problem was my workspace root had eslint as a dev dependency, but I also had a workspace package that depended on an npm package that depended on a different version of eslint, which I assume ended up breaking the hoisting process somehow. All I did was make sure all packages depended on the same version of eslint and the error went away.

Dan Lynch · Answer 54 · Thu Oct 29 2020 08:40:43 GMT+0800 (China Standard Time)

also experiencing this issue. @export-mike 's solution works as a hotfix, thank you

Lucas Picchi · Answer 55 · Mon Nov 09 2020 06:04:11 GMT+0800 (China Standard Time)

Is there any official response/fix roadmap from yarn dev team about this?

Dan · Answer 56 · Mon Nov 09 2020 16:37:59 GMT+0800 (China Standard Time)

My solution was to switch to pnpm. Highly recommend it!

Andrew Schmadel · Answer 57 · Tue Nov 17 2020 03:24:19 GMT+0800 (China Standard Time)

I'm 99% sure this is the same issue as #7734 – can we please close this as a duplicate?

Julien Gonzalez · Answer 58 · Tue Nov 17 2020 03:42:44 GMT+0800 (China Standard Time)

I'm 99% sure this is the same issue as #7734 – can we please close this as a duplicate?

I would prefer if we could keep it open. It has some valuable information about how to reproduce. The other issue feels more like a "i have the same issue" and "downgrading worked for me" kind of thread in comparison.

Linking the two and possibly getting similar issues under a common label would help but closing this isn't going to revive the discussion on the other one.

Dan Lynch · Answer 59 · Tue Nov 17 2020 13:43:26 GMT+0800 (China Standard Time)

agree @customcommander and FWIW, this issue is the one that google continues to bring up when googling the error since I literally run into this problem every other day 😂

I am working in many workspaces and this issue has for some reason, become more prevalent lately.

Yang · Answer 60 · Thu Nov 19 2020 16:28:18 GMT+0800 (China Standard Time)

node:v14.15.0
yarn:1.22.10

~~I also encountered this problem, and my solution was to delete the yarn.lock file and re-execute the yarn install command, and the problem was solved~~

ps: I had this problem after upgrading my MAC system to Big Sur

This method is not recommended because reinstalling Packages can change the current running environment and cause unpredictable problems

James · Answer 61 · Wed Nov 25 2020 06:22:44 GMT+0800 (China Standard Time)

node:v14.15.0
yarn:1.22.10

I also encountered this problem, and my solution was to delete the yarn.lock file and re-execute the yarn install command, and the problem was solved

ps: I had this problem after upgrading my MAC system to Big Sur

Deleting your yarn.lock isn't a valid solution, you should never delete your yarn.lock without knowing exactly what you're doing. I learned this one the hard way.

Lucas Picchi · Answer 62 · Thu Nov 26 2020 03:05:18 GMT+0800 (China Standard Time)

To extend @jamesdbruner warning, deleting your yarn.lock file will cause yarn to update all your packages. If dependency versions where not locked down, then every time the dependencies are installed through yarn install, the fetched dependencies may be different. If one of the dependencies has a new version available and the available version is within the specified version range in the package.json, then the newest dependency will be installed. This could be very dangerous, mostly if your version range in the package.json allows major update (because this updates can have public API changes), but sometimes you can find a new bug when updating minor versions too. The nature of yarn.lock is to have complete control over which version of a dependency is used to have a stable enviroment for development.

FrozenKiwi · Answer 63 · Thu Dec 10 2020 05:43:40 GMT+0800 (China Standard Time)

a slightly simpler workaround: directly add your dependency to package.json and then run yarn in the project root.

worked for me, yarn 1.22.4 on monorepo/lerna

Joey Figaro · Answer 64 · Tue Dec 15 2020 07:02:27 GMT+0800 (China Standard Time)

Any updates or progress on investigating this? Using yarn policies set-version to rollback/specify a different version does not fix the issue for us. Only workaround currently is to add packages to package.json by hand prior to install.

Mirko Kruschke · Answer 65 · Tue Jan 12 2021 02:04:41 GMT+0800 (China Standard Time)

Hi, unfortunately we encountered the same issue after upgrading to a newer babel version and adding one or two additional eslint plugins. The package that is doing a violation is already added in the package.json on the root level.

As workaround I downgraded to v1.18.0. We used before 1.22.10 and also 1.19.2 had the same issue (see screenshot)

Matthias John · Answer 66 · Tue Jan 12 2021 19:54:51 GMT+0800 (China Standard Time)

Hi, unfortunately we encountered the same issue after upgrading to a newer babel version and adding one or two additional eslint plugins. The package that is doing a violation is already added in the package.json on the root level.

As workaround I downgraded to v1.18.0. We used before 1.22.10 and also 1.19.2 had the same issue (see screenshot)

@MKruschke This bug can be fixed, without downgrading to v1.18.0, if you add the following to your package.json

"resolutions": {
    "**/@babel/traverse": "PLACE_YOUR_BABEL_TRAVERSE_VERSION_HERE"
  },

Joaquín Artola · Answer 67 · Fri Mar 19 2021 02:02:49 GMT+0800 (China Standard Time)

I just had the same problem on a monorepo Lerna + Yarn (v1.22). Solved re-creating the yarn.lock.

THANKS! Delete root yarn.lock!

nikaupp · Answer 68 · Fri Mar 26 2021 02:22:51 GMT+0800 (China Standard Time)

deleting yarn.lock helped to solve this for me.

Bryan Vaz · Answer 69 · Sun Apr 11 2021 00:20:54 GMT+0800 (China Standard Time)

Just an FYI to anyone who hits this problem and is on yarn > 1.18 and it happens after running yarn upgrade,
this is how you fix the issue without destroying your entire monorepo:

DO NOT DELETE YOUR yarn.lock!!
This will likely cause a cascade of compatibility issues for you app (issues scale exponentially based on the number of dependancies you have and how large/old your app is).
Stash your changes with git stash or what ever code versioning you use if you have other changes beside the yarn upgrade. Your yarn.lock is corrupted beyond repair at this point.
Hard reset back to before you ran yarn upgrade. - This restores the yarn.lock that is correct and still works.
Optional: Reset your node environment. I use nvm, so I just bumped up to the newest LTS release. You don't have to do this, but if you're paranoid, it doesn't hurt.
Remove your yarn > 1.18 and install yarn 1.18 globally. For some reason, just setting the yarn policy for the monorepo may not work (caused by certain operations using the global version, not the local policy version - I don't know which ones, but there's no margin for error when you are in this situation as you will have to start again if the wrong version of yarn runs even once during the upgrade operation).
If you reset your node environment like me, you can just run npm i -g yarn@1.18.
Optional: Run yarn policies set-version 1.18.0. We did this to ensure all developers are running 1.18 minimizing the chance of the lock file corrupting.
Perform your yarn upgrade operations. Remember that if you upgrade the version of a dependency in one workspace, YOU MUST upgrade the dependency version in all workspaces, if you want to go back to a new version of yarn after upgrading.
Even if you do not go back to a newer version of yarn this is still recommended to prevent mismatched dependency versions from running. We suspect that yarn workspaces is not resolving dependency trees correctly when different top level dependencies are specified across workspaces.
Optional: Restore the newer version of yarn if you need to.
Apply your git stash, but reject all yarn.lock and package.json changes in your stash as those are corrupted.

Anyone who is currently running lerna and yarn workspaces should roll back to yarn 1.18 when performing upgrades just as a precaution. This issue seems to appear when you have multiple large projects in a single monorepo that share the same "complex" dependencies (with at least 2+ levels of dependencies below). When upgrading the dependencies in a single project, if the new version of the dependency has a new sub-dependency, yarn >= 1.19 does not resolve the new dependency tree correctly. Yarn's workspace checker appears to expects that all occurrences of the dependency throughout the monorepo to have the new sub-dependency, even though the other projects are using an older version that does not require it - at which point yarn breaks and refuses to perform any new upgrades.

Upgrading all instances of the dependency to the same new version using yarn 1.18 allows the yarn.lock file to be structured correctly. Then after the upgrade, you can switch back to the newest version of yarn and everything should work fine.

For larger teams, I recommend performing the upgrades in a container (e.g. docker.) This ensures the environments are clean and the yarn.lock files resolve and generate correctly, without having to alter your local environment.

Lucas Picchi · Answer 70 · Sun Apr 11 2021 01:39:13 GMT+0800 (China Standard Time)

Does yarn team acknowledge this as a bug? Or we are doom to use older yarn version in our repos?

Kyle Holmberg · Answer 71 · Sun Apr 11 2021 01:51:09 GMT+0800 (China Standard Time)

I think the guidance from the yarn team is to move to yarn 2.

Bryan Vaz · Answer 72 · Sun Apr 11 2021 01:54:19 GMT+0800 (China Standard Time)

Not sure if it is a bug present in yarn@2, but we're testing yarn@2 next week under the same conditions to see if the same error crops up.

If anyone else has encountered this error, try upgrading to yarn@2. It would be useful to have more than 1 datapoint.

Also note that you have to revert back to yarn@1.22 before you can upgrade to yarn@2. yarn@1.18 does not have the yarn set command needed to upgrade using the defined migration instructions

Cheers,
Bryan

Andrew Schmadel · Answer 73 · Wed Apr 14 2021 07:15:03 GMT+0800 (China Standard Time)

If you're one of the many who are impacted by this issue, don't get your hopes up for a bugfix – Yarn 1 appears to have been quietly deprecated, and the maintainers no longer appear to be reviewing pull-requests in this repository.

If Yarn 2 doesn't work for you, consider switching to npm or pnpm.

Mike Marcacci · Answer 74 · Sat Apr 17 2021 07:31:34 GMT+0800 (China Standard Time)

FWIW I've slowly come to understand this bug more. It's very much still alive.

In particular the flaw appears to be a discrepancy between yarn planning dependencies and then executing. On a multi-workspace repo, I often run into this when performing a yarn upgrade-interactive --latest. However, running a yarn upgrade followed by another yarn upgrade-interactive --latest will almost always allow it to proceed. Interestingly, running another yarn upgrade often updates the lockfile further.

Essentially, my workaround is to alternate between yarn upgrade-interactive --latest and yarn upgrade until they succeed and make no further changes.

What I think is happening:

yarn calculates its target optimized directory structure based on the latest matching versions
yarn then plans its order of installation based on the assumption that transitive dependencies will exist at the "optimal" (flattest) level
yarn executes upgrades on each workspace, one-at-a-time and the mismatches between the some-new/some-old workspaces results in nested dependencies (instead of the optimized "flatter" structure it was expecting), which are not available to subsequent workspaces

This is all speculation based on behavior and without any understanding of yarn's internals... but it follows what I imagine could be an easy false assumption when writing an optimizer and execution planner, and I figured I would toss this here in case it nudges somebody more familiar with the codebase toward a solution.

Vitor Gratiere Torres · Answer 75 · Fri Jun 25 2021 09:06:55 GMT+0800 (China Standard Time)

Not sure if it is a bug present in yarn@2, but we're testing yarn@2 next week under the same conditions to see if the same error crops up.

@bryanvaz do you have any update on this? How did it went?

Viktor Varland · Answer 76 · Fri Jun 25 2021 15:05:35 GMT+0800 (China Standard Time)

Your mileage may vary on this one.

We've had success using yarn-deduplicate to "solve" this situation: https://github.com/atlassian/yarn-deduplicate

Eventually the yarn.lock grows in complexity again and the problem pops up, so then we need to run npx yarn-deduplicate yarn.lock again to resolve it.

It changes your lockfile so some form of regression testing is necessary.

Khaled Osman · Answer 77 · Mon Aug 02 2021 21:03:23 GMT+0800 (China Standard Time)

200 IQ "fix":
instead of using yarn add, manually add the dependency to package.json

Giau. Tran Minh · Answer 78 · Sat Dec 11 2021 10:40:13 GMT+0800 (China Standard Time)

200 IQ "fix": instead of using yarn add, manually add the dependency to package.json

I ran into this issue when running expo upgrade in a mono-repo, which upgrades ~30 packages for given SDK version. I can't change every package version. So, the only way to do is downgrade yarn to 1.18.0 with
yarn policies set-version 1.18.0

Praveen Ranjan Keshri · Answer 79 · Wed Dec 22 2021 02:50:58 GMT+0800 (China Standard Time)

Did npm install at the end. Phew!

Glenn Dwiyatcita · Answer 80 · Tue Dec 28 2021 20:00:09 GMT+0800 (China Standard Time)

I have been experiencing the same issues since v1.19. yarn upgrade-interactive became unusable; It would fail to apply the version updates.

After updating to v1.21 I'm not able to yarn install anymore. It always throws this error:

expected workspace package to exist for ...

Downgrading to 1.18 fixed both issues.

I should point out that these problems only occur on one project, which is a monorepo that uses lerna and yarn workspaces.

Upgrading to 1.22.17 seems to fix this yarn upgrade-interactive issue for me. I'm also in a monorepo project of lerna with yarn as its npmClient and workspaces. 🚝

Richard Vanbergen · Answer 81 · Thu Dec 30 2021 13:09:07 GMT+0800 (China Standard Time)

Downgrading also works for me although I decided that it'd be better to upgrade to berry in the end. Works fine as long as you're not using zero-installs which I have never managed to make work.

Demian Caldelas · Answer 82 · Wed Jan 19 2022 14:02:13 GMT+0800 (China Standard Time)

An external but simple workaround would be to use volta (a toolchain manager) and pin to the downgrade version of yarn you need. This, of course, is just another alternative to the many workaround solutions proposed on this thread.

Deniss Abramovs · Answer 83 · Wed Jan 19 2022 19:12:32 GMT+0800 (China Standard Time)

This is still reproduced in latest yarn v1.22.17

error An unexpected error occurred: "expected workspace package to exist for \"@typescript-eslint/eslint-plugin\"".
info If you think this is a bug, please open a bug report with the information provided in "/var/local/acp/dashboards/packages/vpn/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.

Ashal Farhan · Answer 84 · Thu Mar 03 2022 13:12:16 GMT+0800 (China Standard Time)

200 IQ "fix": instead of using yarn add, manually add the dependency to package.json

Still facing the same issue here, this is the only workaround that I've tried and works perfectly fine.

yarn: 1.22.17
node: 16.13.2

Clifford Fajardo · Answer 85 · Sat Mar 05 2022 04:30:20 GMT+0800 (China Standard Time)

instead of using yarn add, manually add the dependency to package.json
Resolved by doing this ^, same as last comment ^

yarn: 1.22.17
node: 16.13.2

Trond Bergquist · Answer 86 · Mon Mar 07 2022 16:55:26 GMT+0800 (China Standard Time)

yarn upgrade-interactive is still failing for me

yarn: 1.22.17
node: 16.13.2 && 16.14.0

Ana Cristina Lopez Calero · Answer 87 · Fri Mar 11 2022 17:55:49 GMT+0800 (China Standard Time)

Still failing for me...
yarn workspace test add chance
error An unexpected error occurred: "expected workspace package to exist for \"@jest/core\"".
Yarn: 1.22.17
Node: 16.14.0

Kyle Smith · Answer 88 · Tue Mar 15 2022 04:13:34 GMT+0800 (China Standard Time)

Is downgrading yarn three minor versions using yarn policies still the workaround for this? Worked for me, but seems "bad".

Matthias von Bargen · Answer 89 · Tue Mar 15 2022 04:22:18 GMT+0800 (China Standard Time)

just as an fyi for people still posting in here. This repo is abandoned by the devs and the new "yarn" is over here: https://github.com/yarnpkg/berry

we had to drop yarn completely due to no longer having an upgrade path

Roger Perez · Answer 90 · Thu Mar 17 2022 06:37:04 GMT+0800 (China Standard Time)

I deleted my yarn.lock file and and re-installed. That worked for me.

Kimmy Wang · Answer 91 · Sun Apr 03 2022 20:33:38 GMT+0800 (China Standard Time)

same issue

Glenn Dwiyatcita · Answer 92 · Wed Apr 13 2022 04:43:37 GMT+0800 (China Standard Time)

I deleted my yarn.lock file and and re-installed. That worked for me.

Avoid deleting/re-creating yarn.lock file (it's there for a reason). Instead, try to dedupe its entries and then (re-)install.

EDIT (thanks to @as-zlynn-philipps for noticing my typo 😅 ):

npx yarn-deduplicate && yarn install

Zack Lynn-Philipps · Answer 93 · Wed Apr 20 2022 23:42:32 GMT+0800 (China Standard Time)

Avoid deleting/re-creating yarn.lock file (it's there for a reason). Instead, try to dedupe its entries and then (re-)install.
npx yarn-dedupe && yarn install

I have been a full-stack developer for 10 years. I only ever delete my yarn.lock as an absolute last resort. Trust me. And, in the last two months, I've encountered about 5 separate situations where that was the only thing that fixed a work-blocking issue. The issue in this thread is the latest one. The fix is as inexplicable as each issue itself.

So, at this point, I'm pretty desensitized to it. If deleting the yarn.lock saves hours of scouring GitHub issues, docs, and StackOverflow, just heckin' do it. If all your deps are following semver and your ranges are properly scoped in package.json, shouldn't break anything to just get the latest acceptable version of everything. That's my two cents. 🤷‍♂️

Re: deduping, this package actually dedupes: https://medium.com/@bnaya/yarn-deduplicate-the-hero-we-need-f4497a362128

Ryan Cole · Answer 94 · Fri May 27 2022 17:00:37 GMT+0800 (China Standard Time)

It's almost like all this javascript tooling is insane :)

Millions of packages for every conceivable thing, hundreds of megabytes of node_modules, tens of thousands of files... Yarn workspaces seems like it's yet another layer of indirection and abstraction on top of an already hideously complicated stack.

Stephan Müller · Answer 95 · Thu Jul 07 2022 16:14:39 GMT+0800 (China Standard Time)

I had this problem and could solve it by setting all corresponding packages in all workspaces to the same version.

Nantris · Answer 96 · Thu Jul 21 2022 08:44:52 GMT+0800 (China Standard Time)

@as-zlynn-philipps the package you mentioned yarn-dedupe is probably not the one you meant to mention yarn-deduplicate: https://www.npmjs.com/package/yarn-deduplicate

Glenn Dwiyatcita · Answer 97 · Thu Jul 21 2022 15:35:06 GMT+0800 (China Standard Time)

@as-zlynn-philipps the package you mentioned yarn-dedupe is probably not the one you meant to mention yarn-deduplicate: https://www.npmjs.com/package/yarn-deduplicate

@slapbox That was my mistake. He actually corrected it :)

Lena Mikhaylova · Answer 98 · Tue Aug 16 2022 04:01:58 GMT+0800 (China Standard Time)

It stopped failing for me once I fixed my workspace names.

package.json
packages/
    hardhat/
        package.json
     ui/
        package.json

root package.json:

  "name": "web3-boilerplate",
  "private": true,
  "workspaces": ["packages/ui", "packages/hardhat"],
   //etc

packages/hardhat/package.json:

    "name": "@web3-boilerplate/hardhat",
    "version": "1.0.0",
    //etc

I previously had named the packages just hardhat and ui and this seems to have been causing the issue. Changing to @web3-boilerplate/hardhat and @web3-boilerplate/ui seems to have fixed it!!

Steffen Ansorge · Answer 99 · Tue Aug 16 2022 22:53:39 GMT+0800 (China Standard Time)

Instead of downgrading yarn to 1.18.0, @elenamik solution fixed it for us. It was a workspace package.json name: "@..." issue. Thanks!

Also don't forget to remove your yarn.lock.

Leon Heess · Answer 100 · Thu Sep 01 2022 07:45:17 GMT+0800 (China Standard Time)

How can this be? Yarn is broken for 8 months now and nothing is happening? Is the project dead?