Yarn: Échec de l'installation des dépendances dans l'espace de travail : le package d'espace de travail devrait exister

Même comportement lors de la tentative d'ajout d'une dépendance à un package d'espace de travail :

yarn workspace @scope/mypackage add npm-package

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

Détails similaires

Yarn version: 
  1.21.1

Node version: 
  10.17.0

Platform: 
  darwin x64

OS
  macOS 10.15.2

Rencontre avec le même problème avec 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

J'ai trouvé une solution de fonctionnalité de

> yarn policies set-version 1.18.0

ce qui veut dire en gros :

Sous le capot, la commande téléchargera simplement la version à fichier unique à partir du référentiel GitHub, la stockera dans votre projet (dans le dossier .yarn/releases), puis mettra enfin à jour votre configuration pour pointer vers le nouveau fichier (à l'aide de fil-path ).

Voir également cela dans Yarn 1.21.1. Je peux reproduire l'erreur dans mon référentiel lors de l'exécution de yarn upgrade-interactive , _mais_ le remplacement manuel des versions dans package.json fonctionne toujours correctement pour une raison quelconque.

Rencontrer cela aussi:

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

Lorsque vous essayez d'ajouter une dépendance non liée à l'intérieur d'un de mes packages d'espace de travail yarn add @reduxjs/toolkit . L'ajout manuel du dep à package.json suivi d'un yarn fonctionne.

J'ai essayé yarn cache clean et j'ai supprimé les deux dossiers wire.lock et node_modules, aucun changement.

▶ yarn --version
1.21.1

Même erreur ici :

$ 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

Ajout de fil-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: 
{
   ...
}

Je rencontre les mêmes problèmes depuis v1.19 .
yarn upgrade-interactive est devenu inutilisable ; Il ne parviendrait pas à appliquer les mises à jour de version.

Après la mise à jour vers v1.21 je ne peux plus yarn install . Il renvoie toujours cette erreur :

le package d'espace de travail prévu existe pour ...

La rétrogradation à 1.18 résolu les deux problèmes.

Je dois souligner que ces problèmes ne se produisent que sur un seul projet, qui est un monorepo qui utilise lerna et yarn workspaces .

Même expérience que @raspo
Je ne peux plus installer de packages à partir de la ligne de commande dans mon espace de travail activé monorepo.

Je ne voulais pas avoir à déclasser le fil car il vient de mon gestionnaire de paquets, j'ai donc utilisé npx comme une terrible solution de contournement.

npx [email protected] add your-deps-here

Obtenez également ce 1.17 à 1.22. Cela semble être une poignée de packages - commençant par istanbul-lib-instrument . Puis jest-snapshot puis cssstyle plusieurs reprises.

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"
    ]
  },
...
}

Je reçois également cette régression des nouvelles?

idem ici, mise à niveau interactive monorepo et fil sur 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

Comme solution temporaire, utilisez quelque chose yvm et utilisez la version 1.18.0 . Travaille pour moi

yarn policies set-version 1.18.0 fonctionne pour moi - le fil passera automatiquement à cette version juste pour le projet ! si propre!
https://classic.yarnpkg.com/en/docs/cli/policies/

Je viens d'avoir le même problème sur un monorepo Lerna + Yarn (v1.22). Résolu en recréant le yarn.lock .

Cela ressemble à un doublon de #7734.

Courir dans cela pour @storybook/api. La solution de contournement de @nerdyman semble avoir fonctionné pour moi dans l'intervalle.

Je ne voulais pas avoir à déclasser le fil car il vient de mon gestionnaire de paquets, j'ai donc utilisé npx comme une terrible solution de contournement.

npx [email protected] add your-deps-here

c'est du travail pour moi

J'ai eu le même problème et bien que la suppression de yarn.lock et l'exécution de yarn install (ou yarn workspace some-workspace bla bla bla ) aient fonctionné, le problème était que j'utilisais une version plus récente de laine par rapport aux membres de mon équipe .

La solution consistait donc à utiliser yarn policies . Vous exécutez essentiellement yarn policies set-policy et cela téléchargera la dernière version stable de fil et l'enregistrera dans .yarn/ et mettra également à jour votre .yarnrc pour pointer vers la version de fil téléchargée. De cette façon, vous pouvez vous assurer que tout le monde utilise la même version de fil et éviter ce genre de problèmes.

Plus d'infos ici : https://classic.yarnpkg.com/en/docs/cli/policies#toc -policies-set-version

Donc, la solution à ce problème est de déclasser yarn , le fil 2.0 sera amusant

@remorses excuses si j'ai mal lu le sarcasme dans votre réponse. Je n'ai vu personne soumettre un PR pour résoudre ce problème dans 1.x. Il est possible que, dans d'autres problèmes, des personnes aient soumis des correctifs pour ce bogue ou d'autres qui ont été rejetés, et cela me rendrait triste. S'il y a de nombreux PR pour 1.x qui sont ignorés, j'espère que les responsables accueilleront les membres de la communauté qui souhaitent aider à maintenir 1.x. Sans les relations publiques et la maintenance de la communauté, il est difficile de reprocher à quiconque de vouloir se concentrer sur sa branche de développement active.

Cela se produit généralement si vous utilisez une version différente du même package npm dans les espaces de travail.

Disons que vous avez des espaces @scope/api travail @scope/www et @scope/api et que les deux ont eslint package npm @scope/www utilise [email protected] alors que @scope/api utilise [email protected] . De plus, vous avez [email protected] dans la racine packages.json .

Ensuite, si vous essayez d'installer un package sur l'un des espaces de travail, vous obtiendrez error An unexpected error occurred: "expected workspace package to exist for \"eslint\"". erreur eslint n'est identique.

Une fois que vous les avez rendus identiques, vous ne devriez plus obtenir d'erreur.

C'est intéressant, merci pour les détails supplémentaires @abdullahceylan - Juste curieux : Comment Yarn avant 1.19.2 (pas d'erreur) a-t-il géré cette situation ?

Cela me donne également la même erreur @friederbluemle

Je rencontrais ce problème parce que j'avais différentes versions de @babel/core dans mes espaces de travail, comme l' a dit @babel/core jour de

J'aurais aimé qu'il y ait un message plus spécifique pour cette erreur.

J'ai aussi eu ce problème mais j'ai pu le résoudre :
La raison en était que j'avais un package (eslint) dans l'un de mes packages et dans l'espace de travail racine. Je l'ai supprimé de l'espace de travail racine et tout fonctionnait à nouveau.

J'ai découvert que mes problèmes venaient de ce @babel/core dans nextjs a été corrigé sur 7.7.7 et que certains autres modules nécessitaient ^7.10.0 , c'est pourquoi fil met un dossier node_module supplémentaire dans votre package pour résoudre les conflits de dépendances.

Je l'ai résolu en utilisant resolutions en faisant

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

Et a fait un yarn install / npx lerna bootstrap

Dans l'application sur laquelle je travaille, j'ai pu résoudre ce bug en modifiant

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

à

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

Peut-être que yarn détecte accidentellement un espace de travail imbriqué dans les node_modules de l'un de mes packages ? Je n'ai pas eu le temps de m'y pencher. J'utilisais le fil 1.22.4.

EDIT : cela semble être corroboré par les affirmations selon lesquelles la consolidation des versions de dépendance (qui à son tour les sort du répertoire packages ) peut également résoudre ce problème.

ce qui a fonctionné pour moi c'est

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

vous pouvez utiliser npx au lieu de yarn ici

Idem ici yarn add explose complètement en essayant de faire n'importe quel package. Veuillez corriger

Tout à coup, je suis tombé sur ça à l'improviste.

Edit: j'avais un package local sur mon mono-repo avec le même nom qu'une dépendance npm, comme mentionné par @abdullahceylan.

J'ai eu le même problème avec yarn add . Dans mon cas, il se plaignait de eslint . J'ai défini manuellement la version eslint sur 7.2.0 .
J'ai parcouru mon yarn.lock pour vérifier quelles dépendances demandaient une version différente de eslint (juste utilisé l'outil "Rechercher" avec le mot-clé eslint ).
J'ai réalisé que de nombreuses dépendances nécessitaient la version 6.8.0 et qu'ils essayaient de l'installer.

J'ai résolu le problème en définissant la version eslint sur 6.8.0 .
Soit vous pouvez choisir d'ajouter le paramètre resolutions à votre fichier package.json . Dans mon cas, ça aurait été comme

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

J'espère que ça pourra aider quelqu'un.

Merci beaucoup @dxit , ça m'aide

Quelqu'un a-t-il pu identifier la cause exacte de cela? Y aura-t-il un correctif inclus dans la v1 ?

Rencontrer la même chose sur un monorepo qui utilise le levage. Contourner cela avec le hack npx pour installer deps.

En supposant que vous utilisez Lerna, @mmun votre correctif peut être lié à un ordre de résolution incorrect concernant les packages qui dépendent les uns des autres. Voir ici pour plus de détails.

J'ai eu cette erreur avec l'environnement ci-dessous:

Node: 10.20.1
Yarn: 1.22.4

Cela fonctionnait avec le réglage ci-dessous.

Node: 10.15.3
Yarn: 1.13.0

J'ai essayé de définir Yarn sur 1.18.0 mais il semble que cela ne fonctionne pas avec Node 10.20.1

Note à moi-même : revoyez-la une fois que la prochaine version de yarn sera publiée.

@dkempner fil 1 fil@berry tho

Après avoir testé chaque version, le bogue commence en 1.19.2, au moins pour Windows. Donc quelques changements entre les pauses 1.19.1 - 1.19.2

@ thefat32 -

npx [email protected] upgrade-interactive

J'ai le même problème lorsque j'ajoute une dépendance au monorepo de fil.

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

Salut les gars, j'ai eu exactement le même problème!

An unexpected error occurred: "expected workspace package to exist for \"@jest-cli"".
Je rencontrais ce problème car j'avais une version différente de jest-cli dans mon espace de travail. Résolu en mettant à niveau tous les packages vers la dernière version.

@abdullahceylan Savez-vous si c'est toujours le cas avec les dépendances _transitive_ ? J'ai le même échec que tout le monde mais dans mon cas la dépendance n'est pas la mienne donc je ne sais pas comment je pourrais la mettre à niveau. Et est-ce que workspaces.nohoist change quelque chose ?

@customcommander TBH Je n'ai pas rencontré de situation comme la vôtre, mais la première chose que j'essaierais dans une telle situation serait d'utiliser quelque chose comme "**/pagkage-name" pour l'option nohoist .

Publié sur Stack Overflow ; Au cas où
Pourquoi Yarn lance-t-il « Invariant Violation : un package d'espace de travail attendu pour exister » lorsque j'essaie de mettre à niveau certaines dépendances ?

@customcommander TBH Je n'ai pas rencontré de situation comme la vôtre, mais la première chose que j'essaierais dans une telle situation serait d'utiliser quelque chose comme "**/pagkage-name" pour l'option nohoist .

Pourquoi?

Je vis actuellement cela avec lerna

Nous avons réduit cela pour commencer à se produire pour nous dans v1.19.2

Nœud : v12.13.0
fil : fonctionne <= v1.19.1
Système d'exploitation : macOS 10.15.6

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

yarn policies set-version 1.19.1 fonctionne pour nous avec lerna

Changer les politiques de fil en yarn policies set-version 1.18.0 fonctionné pour moi aussi.
J'étais dedans:
Fils: 1.22.5
Nœud : 10.21
OS : Arch Linux (x64)

Je n'ai pas de solution au-delà de celles déjà suggérées dans ce fil, mais il semble que PR https://github.com/yarnpkg/yarn/pull/7289 soit l'endroit où la régression a été introduite, et plus précisément, ces lignes .

La version de ce bogue que j'ai rencontrée est particulièrement déroutante car la dépendance indiquée dans le message d'erreur n'a été installée que dans la racine de l'espace de travail, et non dans l'un des espaces de travail imbriqués.

J'ai créé une reproduction minimale ici : https://github.com/smably/yarn-workspaces-hoisting-bug. Dans ce cas, j'obtenais expected workspace package to exist for "pretty-quick" même si pretty-quick n'apparaît qu'une seule fois dans l'arborescence. L'erreur réelle semble se produire lorsque le fil essaie de soulever les dépendances transitives de pretty-quick .

J'ai essayé de fouiller dans la base de code de fil pour voir si je pouvais résoudre le problème, mais bon nombre des tests unitaires échouent sur ma machine, le lien "contribuer" dans le README est rompu et j'ai eu beaucoup de mal à déboguer parce que je n'ai pas pu faire fonctionner les instructions console.log ou debugger (je suppose parce que yarn génère des processus enfants et ils n'héritent pas des --inspect du nœud

Dans mon cas, cela pourrait être les conflits de version de @babel/core . Je l'ai résolu en : consultez la version installée par yarn why @babel/core , ajoutez une résolution au package qui n'est pas la même version pour unifier la version.

L'ajout de ceci au cas où quelqu'un d'autre (que Dieu les aide) a un problème similaire car je viens de passer la moitié de mon week-end à déboguer / reformater essentiellement mon ordinateur ...

J'ai mis yarn policies set-version 1.19.1 pensant que tout allait bien. Quelques heures plus tard, j'ai créé mon application Next.js et j'ai obtenu ce Error occurred prerendering page... . J'ai littéralement tout essayé sous le soleil, et je viens de réaliser que faire yarn policies set-version 1.19.1 était la cause.

Ce qui est encore plus étrange, c'est que cela détruit mon projet local. Si je passe à une branche stable, supprime tous les modules de nœud, fil.lock, etc., reviens à la dernière version de fil et lance yarn install , puis reconstruis à nouveau mon application Next.js, j'obtiens la même chose Erreur.

Je n'ai aucune idée de ce qui se passe tbh. J'ai littéralement réinstallé le nœud, le fil, etc. La seule solution était de supprimer l'application et de la cloner à nouveau.

J'ai eu le même problème avec le package eslint . Il s'avère que le problème était que la racine de mon espace de travail avait eslint en tant que dépendance de développement, mais j'avais également un package d'espace de travail qui dépendait d'un package npm qui dépendait d'une version différente d'eslint, ce qui, je suppose, a fini par interrompre le processus de levage d'une manière ou d'une autre. Tout ce que j'ai fait, c'est m'assurer que tous les packages dépendent de la même version d'eslint et que l'erreur a disparu.

connaît également ce problème. La solution de @export-mike fonctionne comme un correctif, merci

Existe-t-il une feuille de route officielle de réponse/correction de la part de l'équipe de développement de fil à ce sujet ?

Ma solution était de passer à pnpm. Je le recommande vivement !