yarnpkg / yarn

The 1.x line is frozen - features and bugfixes now happen on https://github.com/yarnpkg/berry
https://classic.yarnpkg.com
Other
41.44k stars 2.73k forks source link

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

Open zamotany opened 4 years ago

zamotany commented 4 years ago

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

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

What is the expected behavior?

yarn install should successfully install dependencies.

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

sam-b-rose commented 4 years ago

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
klaasman commented 4 years ago

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

schmod commented 4 years ago

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.

mgcrea commented 4 years ago

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
necrifede commented 4 years ago

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: 
{
   ...
}
raspo commented 4 years ago

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.

wesgro commented 4 years ago

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

nerdyman commented 4 years ago

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
mayteio commented 4 years ago

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"
    ]
  },
...
}
pitops commented 4 years ago

I am also getting this regression any news?

OzzyCzech commented 4 years ago

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
pitops commented 4 years ago

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

export-mike commented 4 years ago

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/

LasaleFamine commented 4 years ago

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

smith commented 4 years ago

This looks like a duplicate of #7734.

mhuggins commented 4 years ago

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

xiaoTuiMao commented 4 years ago

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

americos commented 4 years ago

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

remorses commented 4 years ago

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

tilgovi commented 4 years ago

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

abdullahceylan commented 4 years ago

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.

friederbluemle commented 4 years ago

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

abdullahceylan commented 4 years ago

It also gives the same error to me @friederbluemle

mkhbragg commented 4 years ago

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! 🙏

vandamm commented 4 years ago

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

feedm3 commented 4 years ago

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.

LennardWesterveld commented 4 years ago

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

mmun commented 4 years ago

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.

havenchyk commented 4 years ago

what worked for me is

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

you can use npx instead of yarn here

jwaldrip commented 4 years ago

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

Nantris commented 4 years ago

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.

dxit commented 4 years ago

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.

nathanielks commented 4 years ago

Many thanks @dxit, that helps me 😄

aecorredor commented 4 years ago

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.

kylemh commented 4 years ago

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 commented 4 years ago

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

dkempner commented 4 years ago

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

kylemh commented 4 years ago

@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

thefat32 commented 4 years ago

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

friederbluemle commented 4 years ago

@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
heavenkiller2018 commented 4 years ago

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 commented 4 years ago

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.

customcommander commented 4 years ago

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

abdullahceylan commented 4 years ago

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

customcommander commented 4 years ago

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?

zhiqingchen commented 4 years ago

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

mattvb91 commented 4 years ago

Currently experiencing this with lerna

knowroozi commented 4 years ago

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

https://github.com/yarnpkg/yarn/compare/v1.19.1...v1.19.2

yarn policies set-version 1.19.1 works for us with lerna

mancier commented 4 years ago

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)

smably commented 4 years ago

I don't have a solution beyond the ones already suggested in this thread, but it seems that PR https://github.com/yarnpkg/yarn/pull/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.