<p>l'installation de fil échoue avec `ENOENT: aucun fichier ou répertoire de ce type` occasionnellement</p>

Intéressant, il échoue donc uniquement sur Travis, mais fonctionne lors de tests en local? C'est très étrange étant donné que Docker est censé s'assurer que l'environnement est cohérent.

@ Daniel15 je sais bien ...

J'ai rétrogradé le nœud à la version 6 et il échoue toujours sur Travis. J'ai ajouté l'indicateur --verbose à yarn install et tout ce que j'ai obtenu était

verbose Performing "GET" request to "https://registry.yarnpkg.com/spawn-wrap/-/spawn-wrap-1.3.4.tgz".
verbose Performing "GET" request to "https://registry.yarnpkg.com/yargs/-/yargs-6.6.0.tgz".
verbose Performing "GET" request to "https://registry.yarnpkg.com/yargs-parser/-/yargs-parser-4.2.1.tgz".
verbose Performing "GET" request to "https://registry.yarnpkg.com/fibers/-/fibers-1.0.15.tgz".
verbose Performing "GET" request to "https://registry.yarnpkg.com/selenium-standalone/-/selenium-standalone-5.11.2.tgz".
verbose Performing "GET" request to "https://registry.yarnpkg.com/tcp-port-used/-/tcp-port-used-0.1.2.tgz".
verbose Performing "GET" request to "https://registry.yarnpkg.com/babel-runtime/-/babel-runtime-5.8.38.tgz".
verbose Error: ENOTEMPTY: directory not empty, rmdir '/usr/local/share/.cache/yarn/npm-webdriverio-4.6.2-dd095ee618896a21c8f1b9d4278736d85a64ca0f/lib/protocol'
    at Error (native)
error An unexpected error occurred: "ENOTEMPTY: directory not empty, rmdir '/usr/local/share/.cache/yarn/npm-webdriverio-4.6.2-dd095ee618896a21c8f1b9d4278736d85a64ca0f/lib/protocol'".

Je suis ouvert aux idées sur la façon de déboguer cela.

Le déclassement en fil 0.18.1 a semblé résoudre ce problème pour moi. On dirait que 0.19 pourrait avoir une régression; voir # 1834

J'ai aussi ce problème avec le fil 0.23.3, cela ne se produit pas lors de la construction d'une image mais simplement lors de l'exécution d'un CI.
L'erreur est la suivante:

$ time yarn --frozen-lockfile
yarn install v0.20.3
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "ENOTEMPTY: directory not empty, rmdir '/builds/linagora/petals-cockpit/yarncache/npm-@angular/core-4.0.0-beta.8-8d9c8a64e7c26ff7208404e716deea94bb509cd7/src'".
info If you think this is a bug, please open a bug report with the information provided in "/builds/linagora/petals-cockpit/frontend/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

real    0m9.812s
user    0m7.596s
sys 0m0.932s

Je pense qu'il peut y avoir une étrange façon de supprimer des fichiers…

Point important: le cache était vide!

Et sur ma machine, si j'essaye de repro, j'obtiens ceci:

yarn install v0.20.3
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "http://docker0.gso.lan:8081/repository/npm/@angular/core/-/core-4.0.0-beta.8.tgz: EEXIST: file already exists, mkdir '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-beta.8-8d9c8a64e7c26ff7208404e716deea94bb509cd7/src/metadata'".
info If you think this is a bug, please open a bug report with the information provided in "/home/vnoel/Linagora/Petals/dev/git/petals-cockpit-new/frontend/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

Et avec du fil 0.21.2:

yarn install v0.21.2
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "http://docker0.gso.lan:8081/repository/npm/@angular/core/-/core-4.0.0-beta.8.tgz: ENOENT: no such file or directory, lstat '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-beta.8-8d9c8a64e7c26ff7208404e716deea94bb509cd7/bundles/core.umd.js'".
info If you think this is a bug, please open a bug report with the information provided in "/home/vnoel/Linagora/Petals/dev/git/petals-cockpit-new/frontend/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

C'est terrible!

Et je suis d'accord avec @twooster à propos de 0.18.1 qui fonctionne bien!

@ Daniel15 cela ne fonctionne pas non plus localement. En fait, cela ne fonctionne JAMAIS lorsque le cache est vide pour moi!

@victornoel l'erreur récente pourrait être https://github.com/yarnpkg/yarn/issues/2714

@bestander J'ai essayé la version 0.19.1 à l'époque et cela n'a pas fonctionné ...

J'ai réessayé, et maintenant le bug:

• n'apparaît pas avec un cache vide, mais apparaît dans le cas suivant (j'espère vraiment qu'il est reproductible…):
  
  
  
  • rm -rf le cache de fils
  
  
  • clone https://gitlab.com/linagora/petals-cockpit.git
  
  
  • caisse 5f31ccb4b2357201baa50539b30702cffceb6992
  
  
  • lancez yarn dans le répertoire frontend
  
  
  • maître de caisse
  
  
  • relancez yarn dans le répertoire frontend
  
  
  • J'obtiens: error An unexpected error occurred: "http://docker0.gso.lan:8081/repository/npm/@angular/core/-/core-4.0.0-rc.1.tgz: ENOENT: no such file or directory, utime '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/@angular/core/testing.js'". (j'utilise mon propre registre, mais la même chose se passe sans elle)
  
  
• apparaît avec le fil 0.21.2, 0.19.1 mais pas avec 0.18.2

Donc je ne pense pas que ce soit la même chose, espérons que vous pourrez au moins le reproduire ...

(en fait, je viens de réessayer et de reproduire le bogue avec un cache vide et du fil 0.21.2 alors que ce n'était pas le cas avant, peut-être qu'il y a un autre fichier ailleurs qui est la source de ce problème, et qui n'est pas dans le cache?)

@bestander Je

Ping moi si je peux aider.
La meilleure action est d'envoyer un PR avec un test e2e cassé (et ignoré).

@bestander eh bien, non, j'obtiens toujours des erreurs telles que:

➜  frontend git:(master) ✗ yarn
yarn install v0.22.0-20170227.1509
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/@angular/core/-/core-4.0.0-rc.1.tgz: ENOENT: no such file or directory, lstat '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/typings/src/facade/lang.d.ts'".

ou:

➜  frontend git:(master) ✗ yarn
yarn install v0.22.0-20170227.1509
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/typescript/-/typescript-2.2.1.tgz: ENOENT: no such file or directory, lstat '/home/vnoel/.cache/yarn/npm-typescript-2.2.1-4862b662b988a4c8ff691cc7969622d24db76ae9/lib/typescriptServices.js'".

Je vais voir si je peux faire un test e2e.

@bestander quand même puis-je obtenir une trace complète de l'erreur?

Je ne vois cela que dans le yarn-error.log:

Trace: 
  Error: http://docker0.gso.lan:8081/repository/npm/@angular/core/-/core-4.0.0-rc.1.tgz: ENOENT: no such file or directory, lstat '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/@angular/core.es5.js'
      at Error (native)

C'est un peu inutile :)

l'erreur détaillée est:

{ Error: http://docker0.gso.lan:8081/repository/npm/@angular/core/-/core-4.0.0-rc.1.tgz: ENOENT: no such file or directory, lstat '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/@angular/core.js'
    at Error (native)
  errno: -2,
  code: 'ENOENT',
  syscall: 'lstat',
  path: '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/@angular/core.js',
  fstream_type: 'File',
  fstream_path: '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/@angular/core.js',
  fstream_class: 'FileWriter',
  fstream_stack: 
   [ '/home/vnoel/Linagora/Petals/dev/git/yarn/node_modules/fstream/lib/writer.js:285:28',
     '/home/vnoel/Linagora/Petals/dev/git/yarn/node_modules/graceful-fs/polyfills.js:284:29',
     'FSReqWrap.oncomplete (fs.js:123:15)' ] }

Je ne sais pas exactement quoi faire avec ça… ça se passe à package-fetcher.js , ligne 56 exactement, j'ai du mal à trouver la source cependant…

Cela semble stupide, mais j'ai l'impression qu'il n'échoue que lorsque mon miroir npm en réseau (un lien de type sonatype dans mon entreprise) a reflété l'artefact @angular/core . Si ce n'est pas le cas, les choses se passent bien et puis il échoue sur un autre artefact qui est déjà en miroir ( typescript dans ce cas).

Si je retire à la main l'artefact du miroir nexus, cela fonctionne!

Alors… c'est un peu comme si le fil n'arrivait pas à suivre si les choses arrivaient trop vite ^^ parce que quand j'utilise le registre npm normal sans utiliser mon miroir, les choses se passent généralement bien (nous avons une connexion internet lente).
Et cela expliquerait pourquoi il échoue souvent sur les systèmes CI car ils ont généralement des connexions Internet très rapides ...

C'est un peu exagéré de conclure cela, mais cela pourrait aider à trouver l'origine du problème.
WDYT @bestander?

Pour mémoire, je pense que l'erreur provient de l'étape tar.Extract dans le pipeline de récupération, mais je ne suis pas totalement sûr ^^

Merci d'avoir cherché plus,

Je peux reproduire le scénario de https://github.com/yarnpkg/yarn/issues/2629#issuecomment -282745896.
Regardant dedans.

Je reçois

error An unexpected error occurred: "https://registry.yarnpkg.com/typescript/-/typescript-2.2.1.tgz: ENOENT: no such file or directory, lstat '/Users/bestander/Library/Caches/Yarn/npm-typescript-2.2.1-4862b662b988a4c8ff691cc7969622d24db76ae9/lib/typescriptServices.js'".

Cependant, si j'essaye simplement yarn install encore et encore, l'installation finira par la suite.
On dirait que l'explosion du fichier .tgz se termine par une erreur.

Mettre à jour:

• le .tgz semble bien, je peux décompresser manuellement celui qui échoue pendant la phase de récupération
• Je me demande si le package tar génère cette erreur pour une raison quelconque, pourrait-il s'agir de la concurrence?

Un peu d'aide pour enquêter sur les raisons pour lesquelles décompresser ces quelques dépendances (dans mon cas, dactylographié et angular-core) provoque une erreur est la bienvenue.
Concurrence? Bug dans https://github.com/npm/node-tar?

@victornoel , pouvez-vous reproduire le bogue avec yarn install --network-concurrency 1 ?

@bestander avec --network-concurrency 1 le bogue n'apparaît pas (alors que sans lui, il apparaît à chaque fois).
Mais quelle est la valeur par défaut de ce paramètre? Quelle que soit la valeur que je choisis pour cela (1, 2, 4, 8), cela fonctionne, tandis que si je ne le mets pas du tout, cela échoue ...

La valeur par défaut est 15, je peux reproduire le problème avec la concurrence 15 avec un checkout propre de https://gitlab.com/linagora/petals-cockpit.git#075bac4c54fee466568c000c7ffe8025f593e212 .

Excellente nouvelle! Un pas de plus vers une solution ET une solution de contournement :)

Quelques résultats.

TL; DR Je ne sais pas comment le réparer correctement pour de bon, cela nécessite des connaissances plus approfondies sur Node.js.

1. Le réseau peut être éliminé d'éventuels problèmes.
   J'ai configuré un miroir hors ligne pour les fichiers .tgz dans yarn.lock et je peux reproduire le problème avec les packages installés à partir du disque.

Le problème est dans le flux décompresser / décompresser dans le code tarball-fetcher.

1. J'ai essayé une bibliothèque différente qui extrait tar - https://github.com/mafintosh/tar-fs vs https://github.com/npm/node-tar/ actuel
   Aller un peu plus loin - des exceptions se produisent dans le nœud lors de plusieurs opérations mkdirp

Error: ENOENT: no such file or directory, chmod '/Users/bestander/Library/Caches/Yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/typings/src/di/injector.d.ts'
  errno: -2,
  code: 'ENOENT',
  syscall: 'chmod',
  path: '/Users/bestander/Library/Caches/Yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/typings/src/di/injector.d.ts' }

Je pense que core-4.0.0 et typescript-2.2.1 échouent car ils ont pas mal de fichiers et des structures de dossiers profondes, et ils ne parviennent pas à s'installer tout en effectuant de nombreuses opérations mkdir / copy simultanées.

Chaque fois qu'un appel système différent échoue: chmod, rmdir, mkdir, lstat, utime.

Et ce n'est pas quelque chose d'évident dans le code des bibliothèques.

1. Échoue la même chose sur les nœuds 4, 6 et 7.

2. Je n'ai pas pu reproduire l'erreur avec la concurrence définie sur 8, je vais donc envoyer un PR pour réduire la concurrence réseau par défaut.

1. Je me demandais comment la concurrence affecte la vitesse d'installation.

5.1. En utilisant un miroir hors ligne (sans téléchargement), sur mon MBPro 13 ", nettoyez le cache et utilisez node-tar pour décompresser les fichiers.
Concurrence 12 - échoue
Concurrence 8-18 secondes
Concurrence 4-18 secondes
Concurrence 2-21 secondes

5.2. En utilisant un miroir hors ligne (sans téléchargement), sur mon MBPro 13 ", nettoyez le cache et utilisez tar-fs pour décompresser les fichiers.
Concurrence 12-15 secondes
Concurrence 8-15 secondes
Concurrence 4-17 secondes
Concurrence 2-18 secondes

5.3. Télécharger des packages depuis Internet, sur mon MBPro 13 ", nettoyer le cache et utiliser tar-fs pour décompresser les fichiers.
Concurrence 12 - a échoué une fois
Concurrence 8-21 secondes
Concurrence 4-23 secondes
Concurrence 2-34 secondes

On dirait que définir la concurrence sur 8 est suffisamment sûr, il est également logique de changer la bibliothèque tar.
Je vais faire un suivi avec un PR.

Une bonne façon de résoudre ce problème serait de bifurquer https://github.com/mafintosh/tar-fs et de faire des opérations fs plus intelligentes, par exemple en utilisant mkdir pour chaque dossier une seule fois

Le mainteneur de tar-fs semble être actif, peut-être pourrions-nous ouvrir un problème là-bas et voir ce qu'ils savent / proposent à ce sujet?

@victornoel , feriez-vous cela s'il vous plaît?

@bestander fait! mafintosh / tar-fs # 61 :)

J'ai rencontré ce message d'erreur dans un scénario quelque peu similaire lors du test de yarn sur les agents de construction de mes jenkins.

Connaissez-vous les conditions requises pour déclencher ce bogue? Je voudrais remplacer mon système de build npm appels avec yarn pour la vitesse, mais si je dois désactiver Je suis inquiet concurrency il pourrait annuler tout bonus là - bas.

@ProdigySim , comme expliqué dans # 2829 (qui a été fusionné dans yarn master), la réduction de la concurrence réseau n'a pas d'effet important sur les performances du fil. Vous pouvez simplement le définir sur 8 et ça devrait aller. Quoi qu'il en soit, même lors du téléchargement de 8 dépendances à la fois, je ne suis pas sûr que la plupart des lecteurs suivront le débit, donc vous ne perdrez pas beaucoup à coup sûr :)

@victornoel Merci pour l'information. Je ne suis pas sûr que la simple réduction de --network-concurrency suffira dans mon cas, car nous exécuterions également plusieurs instances de fil en parallèle.

Je peux reproduire ce problème même avec --network-concurrency 1 , mais je devrais peut-être ouvrir un autre problème pour cela?

En utilisant le même dépôt de test que vous avez donné ci-dessus:

#!/bin/bash
set -x # echo commands

# Clear yarn cache
rm -rf $(yarn cache dir)

# Clone the repo into two separate spots
git clone https://gitlab.com/linagora/petals-cockpit.git repo1
git clone https://gitlab.com/linagora/petals-cockpit.git repo2

# Run yarn on both in parallel
cd repo1/frontend && yarn --network-concurrency 1 &
cd repo2/frontend && yarn --network-concurrency 1 &

Cela me rapporte l'erreur à chaque fois (4 pour 4 jusqu'à présent)

error An unexpected error occurred: "https://registry.yarnpkg.com/@angular/core/-/core-4.0.0-rc.2.tgz: 
ENOENT: no such file or directory, lstat '/Users/<snip>/Library/Caches/Yarn/npm-@angular/core-4.0.0-rc.2-59535050e5d0e6141417186eee571296f8e9c3d0/@angular/core.es5.js'".

Sur le fil 0.21.3, nœud v4.5.0, OSX 10.11.6

Jusqu'à présent, j'ai été en mesure de contourner ce problème en n'incluant que du fil sur des travaux de construction qui ne fonctionneront jamais en parallèle, ou en utilisant des ensembles de packages complètement différents, mais même dans ce cas, je ne suis pas sûr que ce soit sûr - d'où à propos des conditions racine pour ce bogue.

@ProdigySim
Il s'agit d'un problème distinct, mais lié, causé par le cache de téléchargement global de Yarn. Une solution de contournement consiste à créer un cache différent pour chaque répertoire.

Vous pouvez toujours courir avec --network-concurrency 8 . (Je n'ai en fait aucun problème avec la concurrence réseau illimitée.)

Plus de contexte ici .

@bestander étonnamment, aujourd'hui, le problème est réapparu (déclenché par un tar pour une nouvelle version d'angular ^^) même avec la concurrence réseau à 8, mais uniquement sur mon CI… je l'ai déplacé vers 2 et ça marche (et je ne le fais pas) t vraiment soin si cela prend quelques secondes de plus pour télécharger les dépendances, donc c'est ok pour le moment).
Nous ne semblons pas recevoir de commentaires du projet tar-fs… qui d'autre pourrions-nous contacter pour obtenir de l'aide à ce sujet?

J'ai également ce problème sur mes builds Travis pour OS X. J'ai vidé le cache et défini la concurrence réseau, mais rien n'a aidé.

@kevingelion à quelle valeur avez-vous défini la concurrence réseau? soyez drastique et définissez quelque chose comme 2 pour voir si le problème est celui-ci :)

@victornoel Je l'ai défini sur 1 et 2, et les deux options ont abouti à un échec. J'ai utilisé yarn --mutex network et pas de dés non plus.

@bestander le hack suivant corrige (modifier: PAS) le problème:

diff --git a/src/util/request-manager.js b/src/util/request-manager.js
index e0e134a2..995dac69 100644
--- a/src/util/request-manager.js
+++ b/src/util/request-manager.js
@@ -214,8 +214,7 @@ export default class RequestManager {
     }, params.headers);

     const promise = new Promise((resolve, reject) => {
-      this.queue.push({params, resolve, reject});
-      this.shiftQueue();
+      this.execute({params, resolve, reject});
     });

     // we can't cache a request with a processor

Ce n'est évidemment pas un correctif, il contourne complètement le gestionnaire de requêtes et son système de mise en file d'attente, mais cela montre que le problème vient de ce sous-système.

Merci, Victor!

Le 24 mars 2017 à 18h07, Victor Noël [email protected] a écrit:

@bestander https://github.com/bestander le hack suivant corrige le
problème:

diff --git a / src / util / request-manager.js b / src / util / request-manager.js
index e0e134a2..995dac69 100644
--- a / src / util / request-manager.js
+++ b / src / util / request-manager.js
@@ -214,8 +214,7 @@ exporter la classe par défaut RequestManager {
}, params.headers);

 const promise = new Promise((resolve, reject) => {

• this.queue.push ({paramètres, résoudre, rejeter});
• this.shiftQueue ();
• this.execute ({paramètres, résoudre, rejeter});
  });

 // we can't cache a request with a processor

Evidemment ce n'est pas un correctif, il contourne complètement le gestionnaire de requêtes et
son système de mise en file d'attente, mais il montre que le problème vient de ce
sous-système.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/yarnpkg/yarn/issues/2629#issuecomment-289102067 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/ACBdWF66L-NzAInx7Bhs6V7s7LKahxxUks5rpAZ1gaJpZM4L3JbX
.

Whoups not, it don't: D mais ça améliore un peu les choses

Désolé pour le faux positif, j'étais trop impatient de rapporter mes résultats :)

Cela change les choses parce qu'avant je pouvais exécuter du fil plusieurs fois et cela ne réussirait jamais à télécharger la dépendance angular-core ou le dactylographié (toujours ceux-ci), mais là, il a échoué la première fois, et a réussi la deuxième fois, et j'ai oublié de supprimer le cache entre mes essais, donc j'ai pensé que cela fonctionnait.

Bon ça dépend, maintenant parfois ça marche, parfois ça ne marche pas (avec le hack, donc ce n'est pas un raté total ou ma connexion internet est trop lente en ce moment ...)

Je rencontre cela aussi dans nos builds CI. Après de nombreux tests, j'ai enfin pu reproduire localement.

Encore une fois, cela fonctionne parfois, mais cela échoue souvent avec l'une des erreurs suivantes (ce qui donne l'impression qu'il y a une sorte de condition de concurrence quelque part):

• ENOENT: no such file or directory, lstat 'cache/directory/some-file'
• EEXIST: file already exists, mkdir 'package-name'

Je l'ai isolé dans un package que nous installons directement à partir d'un référentiel privé sur GitHub. Fait intéressant, le package référencé dans le message d'erreur est toujours une dépendance de ce package (et c'est toujours un autre package que nous installons directement à partir de GitHub, mais pas un référentiel privé). Il semble donc qu'un cas de repro installe des packages à partir d'URL GitHub privées qui ont des sous-dépendances également installées à partir de référentiels GitHub (pas nécessairement privés).

Je ne sais pas si cela aide du tout ... Je suis heureux d'essayer d'aider de toutes les manières possibles!

Edit: Je ne sais pas si cela est utile ou non, mais le package de niveau supérieur est répertorié au format "git+ssh://[email protected]/org/package.git#v1.0.0" , et dans l'erreur, la sous-dépendance en cours de téléchargement semble être téléchargée sur https avec une URL de "https://codeload.github.com/org/package/tar.gz/ljasdf08i234098aifj" .

J'enquête un peu plus.
Essayer de construire un script autonome pour les extraits simultanés de tar-fs mais j'ai tendance à penser que le problème vient de la rupture du fichier tar lors du téléchargement.

Trouvé, Doh.

Dans l'exemple de https://github.com/yarnpkg/yarn/issues/2629#issuecomment -282745896 Yarn a des packages en double qui sont téléchargés et extraits en parallèle.
Les doublons sont @angular/core/-/core-4.0.0-rc.1 et typescript/-/typescript-2.2.1.tgz .

Avec une concurrence élevée, nous effectuons simplement une extraction simultanée dans le même dossier de cache.
Je vais étudier pourquoi Yarn ne déduplique pas ces deux paquets et envoie un correctif.

Pas de magie sur le niveau d'extraction OS ou tar.

haha, bon travail @bestander , heureux que nous ayons enfin trouvé le problème!

Super travail @bestander : tada:! Rencontrer à la fois https://github.com/yarnpkg/yarn/pull/3090 et https://github.com/yarnpkg/yarn/pull/3106 était ce qui nous a empêchés d'utiliser Yarn.

Merci!

J'ai eu ce problème lors de l'installation du module prop-types. Chaque fois que j'essayais de l'installer, cela ENOENT sur un nom de fichier différent. Pour moi, le problème a disparu après l'installation de npm 5.0.2

$ yarn add prop-types
yarn add v0.21.3
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/prop-types/-/prop-types-15.5.10.tgz: ENOENT: no such file or directory
....

$ npm -g install npm

# whoops, looks like npm installed itself to different location than apt-get did
$ npm -v 
3.5.2

# remove the cached link from shell so the right version can surface
$ hash -d npm
$ npm -v
5.0.2

$ yarn add prop-types
... properly installs prop-types as expected

@skylize C'est probablement une coïncidence - Yarn n'utilise pas du tout le client npm, donc la version de npm n'affecte pas du tout l'exécution de Yarn.

Cela provoque l'échec de mes builds Travis presque à chaque fois, avec quelques packages différents. Y a-t-il encore une solution?
error An unexpected error occurred: "https://registry.yarnpkg.com/apollo-client/-/apollo-client-1.8.0.tgz: ENOENT: no such file or directory, utime '/var/lib/jenkins/.cache/yarn/v1/npm-apollo-client-1.8.0-3b5d1976a06a0f82b2fc66fe71754868193dadb9/flow-typed/npm/webpack_vx.x.x.js'".

@Redmega
Même chose ici, mais cela fonctionne:

yarn install --network-concurrency 1

Quelle version utilisez-vous? Ceci est censé être déjà corrigé ...

Le 8 août 2017 18:37, "Ben Merckx" [email protected] a écrit:

@Redmega https://github.com/redmega
Même chose ici, mais cela fonctionne:

yarn install --network-concurrence 1

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/yarnpkg/yarn/issues/2629#issuecomment-321011749 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AAJ0z5qFb7gSW4w14_RbFNjsn4sRYV78ks5sWI7hgaJpZM4L3JbX
.

@victornoel J'utilise v0.27.5 sur la machine jenkins, comme mon local.

Veuillez essayer les nightlies: https://yarnpkg.com/en/docs/nightly

La suppression du fichier yarn.lock et de yarn install résolu le problème pour moi.

Cela provoque également des échecs occasionnels de mes builds Jenkins. Habituellement, cela fonctionne après un deuxième essai mais échouera à nouveau plus tard.

@ajcrites @Redmega @headione @benmerckx vous devriez ouvrir un autre problème si vous rencontrez ce genre de problème. Ce problème a été résolu à coup sûr, votre problème doit donc être différent, même s'il présente des symptômes similaires.
Je suis presque sûr qu'il y a plus de chances que votre problème soit résolu si vous ouvrez un autre problème :)

Nous avons le même problème, faire des constructions parallèles de paquets dans Jenkins avec Node 8.5. Nous devons actuellement nous en tenir à la version 0.27.5, jusqu'à ce que la version 1.0.2 corrige un autre bogue. Mais merci pour votre soutien et votre travail quand même :)

@floric J'obtiens le même problème avec le même contexte (Jenkins + Parallel) avec le nœud 8.9.4, votre problème a-t-il été résolu?

Edit: J'essaierai d'utiliser 8.11.1 pour voir s'il inclut une dernière version de fil sans le bogue.

@Niceplace, vous --mutex : https://yarnpkg.com/en/docs/cli#toc -concurrency-and-mutex

Nous prévoyons d'ajouter un meilleur verrouillage par paquet pour éviter cela bientôt.

J'ai des erreurs intermittentes avec ENOENT: no such file or directory, chmod et ENOENT: no such file or directory, lstat essayant d'exécuter yarn --mutex=network à la racine d'un monorepo avec l'espace de travail Yarn activé ...

Cela ne semble pas cohérent, j'obtiens l'un ou l'autre au hasard. (1.6.0 et noeud 8.11.1 et 9.11.1)

Plus précisément, les erreurs sont:

error An unexpected error occurred: "ENOENT: no such file or directory, lstat '/Users/federicozivolo/test/packages/foobar/node_modules/detect-port-alt'".

et

error An unexpected error occurred: "ENOENT: no such file or directory, chmod '/Users/federicozivolo/test/packages/foobar/node_modules/jest/node_modules/.bin/jest'".

J'exécute Yarn 1.7.0 et j'ai l'erreur similaire. Yarn parvient enfin à installer le package après plusieurs exécutions.

An unexpected error occurred: "ENOENT: no such file or directory, lstat '/home/nieltg/.cache/yarn/v1/npm-npm-registry-client-8.5.1-8115809c0a4b40938b8a109b8ea74d26c6f5d7f1/lib/dist-tags/fetch.js'".

ÉDITER:
J'ai utilisé yarn --network-concurrency 1 mais l'erreur persiste sur moi. Voici un autre exemple du fichier error et yarn-error.log .

An unexpected error occurred: "ENOENT: no such file or directory, copyfile '/home/nieltg/.cache/yarn/v1/npm-core-js-2.5.7-f972608ff0cead68b841a16a932d0b183791814e/library/fn/date/now.js' -> '/mnt/c/Users/nieltg/Projects/React/React-16-Demo/node_modules/core-js/library/fn/date/now.js'".

J'utilise Yarn 1.7.0. Et je peux confirmer que le même comportement m'arrive encore.

C'est complètement aléatoire. Parfois cela arrive, parfois non.

Le dernier que j'ai reçu était:

error An unexpected error occurred: "ENOENT: no such file or directory, lstat '/root/.yarn-cache/v1/npm-@storybook/addon-actions-3.4.5-ba0d0c0c74357c0852e0b890b40

Je vois cette erreur assez fréquemment avec Yarn 1.9.2 sur le sous-système Windows pour Linux.

Aujourd'hui, nous avons des problèmes similaires avec des packages cassés sur Jenkins CI où le pipeline exécute yarn install en parallèle. Cela fonctionnait très bien il y a quelques jours.
Corrigé avec yarn install --network-concurrency 1 (comme mentionné dans un commentaire ). Les performances ne se sont pas beaucoup dégradées: ~ 7 s -> ~ 8 s.

Pourquoi cela a-t-il été fermé? Cela arrive encore:

Toms-MacBook-Pro-2:design-to-code tommedema$ yarn install
yarn install v1.9.4
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
error An unexpected error occurred: "ENOENT: no such file or directory, lstat '/Users/tommedema/projects/vg/design-to-code/packages/vgcli/node_modules/fs-extra'".
info If you think this is a bug, please open a bug report with the information provided in "/Users/tommedema/projects/vg/design-to-code/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
Toms-MacBook-Pro-2:design-to-code tommedema$ yarn install --network-concurrency 1
yarn install v1.9.4
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
✨  Done in 24.85s.

Notez que dans mon cas, il a disparu après avoir fait yarn remove fs-extra et yarn add fs-extra dans deux packages, améliorant efficacement cette dépendance.

Salut, je pense avoir trouvé quelque chose.

J'étais en train d'essayer un morceau de code qui répertorie les fichiers dans un répertoire spécifié de manière récursive en utilisant fs et rxjs et j'ai découvert qu'il était susceptible d'échouer si je n'attend pas lstat pour terminer avant d'appeler un autre lstat .

J'ai créé un simple package NPM, async-dirtree-test , pour tester si votre environnement est affecté ou non par cela. J'utilise WSL et j'ai trouvé qu'il est susceptible d'échouer lors de la gestion d'un répertoire qui a de nombreux répertoires enfants, comme node_modules , même avec un faible nombre de concurrence.

Eh bien, je ne sais toujours pas si ce problème est spécifique à WSL ou non. Pour le moment, je ne peux pas le tester dans un autre environnement, comme Linux, Mac, etc.

@nieltg Je voulais partager une observation qui pourrait aider à façonner certaines des autres. J'utilise Docker CE dans WSL et Docker pour Windows en tant qu'hôte, donc lorsque je travaille avec Docker dans WSL, cela semble natif, mais en réalité, l'hôte fonctionne dans le monde Windows de manière native (donc mes fichiers Docker résolvent en fait / c / foobar à c: / foobar dans le moteur Docker). Ceci est incroyablement pertinent lorsque j'utilise des liaisons (dans mon conteneur, je monte mes dossiers locaux de sorte que / usr / src à l'intérieur du conteneur soit finalement à c: / src / foobar (bien que mon Dockerfile montre la liaison comme / c / src / foobar: / usr / src (voir la traduction automatique dans le chemin?)

Cette distinction est importante car si je yarn install dans l'un de ces dossiers locaux, dans mon conteneur, j'obtiens les mêmes erreurs que je fais directement dans WSL (aucun Docker impliqué).

D'un autre côté ... si je viens de mkdir /tmp/src && cp ./package.json /tmp/src/ && cd /tmp/src && yarn install , tout réussit parfaitement et je peux juste mv /tmp/src/node_modules /c/src/foobar/ et je vais bien, c'est donc ma solution de contournement actuelle. Notez que /tmp existe en tant que docker store (tous les E / S ressemblent à un seul fichier pour le système d'exploitation car il s'agit en fait d'une partition dans un fichier).

Je sais qu'impliquer docker n'est pas idéal ici, mais cela semble suggérer que les poignées de fichiers rapides pourraient être un problème puisque IO lui-même ne l'est pas et pourrait aider d'autres personnes à contourner ce problème.

... a été distrait et soumis trop tôt. Quoi qu'il en soit, mon cerveau est ailleurs pour le moment, mais je reviendrai plus tard et voir si je peux concevoir un test en utilisant votre approche et Docker pour tirer d'autres conclusions.

ROUVRIR

Nous avons récemment commencé à voir le même type d'erreur en utilisant yarn 1.10.1, en exécutant une build CI dans Azure Devops (anciennement Visual Studio Team Services).

La dépendance réelle qui échoue semble être au mieux aléatoire, mais yarn install tombe par intermittence avec l'erreur ENOENT: no such file or directory, open '/usr/local/share/.cache/yarn........ . Une fois que la construction fonctionnera, la suivante échouera.

La solution de contournement de yarn install --network-concurrency 1 semble fonctionner pour nous.

@ Marclev78 même erreur mais yarn install --network-concurrency 1 ne semble pas fonctionner pour moi

@ Marclev78 même chose ici, en utilisant le fil 1.10.1 dans Azure Devops et en obtenant l'erreur:

Error: https://registry.yarnpkg.com/core-js/-/core-js-1.2.7.tgz: ENOENT: no such file or directory, utime 'C:\Users\grpsshagent\AppData\Local\Yarn\Cache\v1\npm-core-js-1.2.7-652294c14651db28fa93bd2d5ff2983a4f08c636\fn\string\pad-left.js'

Localement, tout fonctionne comme prévu.

Je suis ici pour simplement dire que je vois aussi cette erreur.

error An unexpected error occurred: "ENOENT: no such file or directory, chmod '/usr/local/opt/asdf/installs/nodejs/8.12.0/.npm/bin/atob'".

Malheureusement, je pense que je dois abandonner le fil pour mes binaires de nœuds globaux et revenir à npm jusqu'à ce que cela soit corrigé.

Malheureusement, ce problème a commencé à affliger nos builds CI récemment aussi; (

La suggestion WSL

Je pense que les opérations d'écriture et de lecture se comportent également différemment. Même avec mes hacks, je vois fréquemment des erreurs lors de l'appel de fs.writeFile de node (enveloppé avec bluebird promisify cependant). Dans chaque cas, je peux confirmer que le fichier existe immédiatement après avoir obtenu l'erreur d'écriture.

J'envoie une chaîne (contenu du fichier XML) à fs.writeFile (), qui appelle finalement ce qui suit, mais je ne suis pas sûr si je suis prêt à relever le défi requis pour configurer une version personnalisée avec un débogage supplémentaire sortie de ce projet C ++, afin que je puisse confirmer exactement où le droit se sent réellement en fonction du nœud ou de ce module C ++.

En bout de ligne, les écritures n'échouent pas, mais le nœud pense qu'elles le sont, donc le scénario qui me semble logique est que le module c + plus réussit, mais en interne, il vérifie le fichier et échoue, puis les rapports ne vous sentent pas de retour au nœud puis l'écriture réelle se produit de sorte que lorsque je vais vérifier le fichier, il est là et l'erreur n'a aucun sens.

https://github.com/nodejs/node/blob/master/src/node_file.cc#L1795

@bestander est-il un moyen de faire rouvrir ce problème? De toute évidence, ce n'est pas résolu et cela affecte beaucoup de gens.

Confirmer cela se produit toujours avec yarn 1.12 et Azure Pipelines.

Merci d'avoir confirmé tout le monde.
Il semble qu'il y ait plusieurs raisons à cette erreur.
Je vais rouvrir le problème, l'aide de la communauté pour le déboguer est cependant nécessaire.

se produit également avec le fil 1.11, mais pas avec 1.10

@bestander - Lié? https://github.com/yarnpkg/yarn/issues/6312

Si c'est le cas, il y a du bon travail de repro ici

Je suis également concerné par ce problème.

Windows 10 / WSL

"ENOENT: no such file or directory, lstat '/mnt/c/Users/<username>/.cache/yarn/v4/<random_file_in_random_package>"

@limonte WSL a eu une erreur pendant un certain temps qui lançait au hasard une erreur similaire lors de l'exécution de npm install / yarn install. Cela se produisait lorsque de nombreux fichiers à la fois étaient copiés sur le disque dur. Veuillez vous assurer que vous utilisez la dernière version de Windows (1809 ou supérieure), car cela pourrait ne pas être causé par le fil lui-même.

Nous voyons également le problème de Extracting tar content of undefined .

error https://registry.yarnpkg.com/eslint/-/eslint-4.19.1.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, stat '/tmp/yarncache.KTKNZ/v4/npm-eslint-4.19.1-32d1d653e1d90408854bfb296f076ec7e186a300/node_modules/eslint/lib/rules/no-compare-neg-zero.js'"

Jusqu'à présent, nous avons atténué cela en n'utilisant qu'une seule connexion réseau simultanée avec l'option --network-concurrency 1 . Mais c'est plus une solution temporaire.

Je peux également confirmer le problème sur node:11.5.0-alpine .

error An unexpected error occurred: "ENOENT: no such file or directory, lstat '/app/node_modules/<random_pacakge>

J'ai remarqué que les problèmes semblaient être liés à la liaison vers la version du référentiel git des packages.

Reproduire

package.json

{
  "dependencies": {
    "react-navigation-core": "https://github.com/react-navigation/react-navigation-core",
    "react-navigation-hooks": "https://github.com/react-navigation/react-navigation-hooks"
  }
}

rm -rf node_modules && yarn cache clean && yarn

solution de contournement

La configuration de network-concurrency 1 résout le problème pour moi à chaque fois.

Exécuter npm install fonctionne également.

Remarques

La suppression de l'un ou l'autre des packages de la liste de dépendances ne provoque pas l'erreur, pas plus que l'utilisation des versions npm publiées de ces packages.

Il semble lancer une erreur différente à chaque fois. Cela semble arriver au hasard à différents fichiers et avec des erreurs légèrement différentes.

error https://registry.yarnpkg.com/core-js/-/core-js-1.2.7.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, chmod  '/home/cameron/.cache/yarn/v4/npm-core-js-1.2.7-652294c14651db28fa93bd2d5ff2983a4f08c636/node_modules/core-js/library/modules/es6.reflect.apply.js'"

Variations

• ENOENT: no such file or directory, chmod
• ENOENT: no such file or directory, stat
• ENOENT: no such file or directory, open
• EEXIST: file already exists, mkdir

Autres messages

info There appears to be trouble with your network connection. Retrying...

En effet, je viens d'essayer de reproduire en utilisant votre package.json et une erreur est apparue au premier essai.

Quelle couche le système de fichiers WSL interagit-il avec les fs NTFS déjà en place?

Est-ce que vous voyez cette erreur dans un lecteur monté (/ c ou / mnt / c pour des exemples courants), ou en dehors de l'un de ces montages? Ça vous dérange de tester une alternative (~ /. Par exemple) et de signaler une différence?

Mon intuition me harcèle, mais je peux confondre des problèmes avec mes expériences de docker et je dois vérifier cela indépendamment.

[2/4] Récupération des packages ...
erreur https://registry.yarnpkg.com/smartwrap/-/smartwrap-1.0.10.tgz : l'extraction du contenu tar non défini a échoué, le fichier semble être co
rrupt: "ENOENT: aucun fichier ou répertoire de ce type, ouvrez 'C: \ Users \ Administrator \ AppData \ Local \ Yarn \ Cache \ v4 \ npm-smartwrap-1.0.10-873ef350d
4ee1262fed4a80a55634d86ae1faf48 \ node_modules \ smartwrap \ ejq '"
info Visitez https://yarnpkg.com/en/docs/cli/global pour obtenir de la documentation sur cette commande.

Est-ce que vous voyez cette erreur dans un lecteur monté (/ c ou / mnt / c pour des exemples courants), ou en dehors de l'un de ces montages? Ça vous dérange de tester une alternative (~ /. Par exemple) et de signaler une différence?

Y a-t-il un cas reproductible de manière cohérente où cela se produit? Cela a été assez aléatoire pour moi, mais je fais tout mon yarn add -ing sur un lecteur monté et cela se produit fréquemment.

J'ai pu reproduire https://github.com/yarnpkg/yarn/issues/2629#issuecomment -451638917 à la fois dans un lecteur monté et dans ~ .

J'ai également essayé de reproduire https://github.com/yarnpkg/yarn/issues/2629#issuecomment -282745896 mais il n'arrivait pas à récupérer le dernier paquet, ce qui, j'en suis sûr, n'est pas lié.

J'ai eu le même problème ces dernières heures. yarn échouait au hasard à installer divers packages, montrant les erreurs mentionnées ci-dessus.

J'ai essayé de réinitialiser le cache de fil et de réinstaller et d'exécuter avec la concurrence réseau 1, dont aucun n'avait fonctionné.

Ce qui a résolu le problème pour moi, c'est le passage à un réseau différent (je viens d'utiliser mon téléphone AP au lieu du WiFi) et tout a fonctionné comme par magie.

J'ai l'impression que ce problème pourrait être lié à une récupération mal gérée pour certaines erreurs réseau très spécifiques. Je l'examinerai plus tard.

Je peux confirmer le commentaire précédent. Définir network-concurrency n'aide pas. Le passage au point d'accès téléphonique a résolu le problème pour moi. Mon environnement: Windows 10 (sous-système Linux - Ubuntu)

Je suis sur WSL et j'ai vu ce problème avec le package geo-tz qui a une structure de dossier profondément imbriquée (légèrement étrange). J'ai essayé des choses --network-timeout et --network-concurrency mais je n'ai rien obtenu. Cependant, lorsque j'ai activé les longs chemins sur Windows (voir ce post SuperUser ), cela fonctionne maintenant Modifier il semble que j'ai parlé trop tôt. Cela fonctionnait et la liaison des dépendances est plus rapide, mais maintenant je vois à nouveau la même erreur.

Toujours en rupture de CI ...

Nous avons le même problème avec Yarn 1.13.0 fonctionnant sur une machine Debian Linux qui sert de nœud esclave Jenkins. Notez que nous avons un serveur de référentiel de fils local, donc pendant la construction, il n'y a pas (ou très peu) de téléchargements physiques à partir des serveurs de référentiel public-Internet.

yarn install v1.13.0
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "http://sqrep01.rsint.net:4873/lodash/-/lodash-4.17.10.tgz: ENOENT: no such file or directory, open '/home/jenkins/.cache/yarn/v4/npm-lodash-4.17.10-1b7793cf7259ea38fb3661d4d38b3260af8ae4e7/node_modules/lodash/.yarn-tarball.tgz'".

Le fichier est réel existant, tant sur notre serveur repo et sur le système de fichiers.
Si nous redémarrons la construction, la construction peut réussir ou échouer avec un autre fichier (aléatoire).
Nous n'avons pas modifié le paramètre de concurrence réseau par défaut.

Idem - C'est toujours un problème, même dans 1.14

Arguments: 
  /home/jeff/n/bin/node /usr/share/yarn/bin/yarn.js install

PATH: 
  /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/Windows/System32:/mnt/c/Windows:/mnt/c/Windows/System32/wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0:/mnt/c/Program Files (x86)/NVIDIA Corporation/PhysX/Common:/mnt/c/Windows/System32:/mnt/c/Windows:/mnt/c/Windows/System32/wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0:/mnt/c/Windows/System32/OpenSSH:/mnt/c/Program Files/NVIDIA Corporation/NVIDIA NvDLISR:/mnt/c/Program Files/Git/cmd:/mnt/c/Users/jkono/AppData/Local/Microsoft/WindowsApps:/mnt/c/Users/jkono/AppData/Local/hyper/app-2.1.2/resources/bin:/mnt/c/Users/jkono/AppData/Local/Programs/Microsoft VS Code/bin:/home/jeff/n/bin

Yarn version: 
  1.14.0

Node version: 
  10.15.1

Platform: 
  linux x64

Trace: 
  Error: ENOENT: no such file or directory, scandir '/mnt/c/Users/jkono/dev/PROJECT/node_modules/@storybook/addon-links/src'

Également:

➜  yarn cache dir
/mnt/c/Users/jkono/home/.cache/yarn/v4

C'est assez ennuyeux, on le voit quotidiennement sur les machines locales et ci.

Confirmer que cela se produit tout le temps dans CI pour nous aussi

Bonjour, confirmant que ce problème se produit sur notre CI.
Ceci est conforme au problème.

erreur https://registry.yarnpkg.com/core-js/-/core-js-1.2.7.tgz : L'extraction du contenu tar d'undefined a échoué, le fichier semble être corrompu: "ENOENT: aucun fichier ou répertoire de ce type, chmod '/usr/local/share/.cache/yarn/v4/npm-core-js-1.2.7-652294c14651db28fa93bd2d5ff2983a4f08c636/node_modules/core-js/es7/regexp.js' "
info Visitez https://yarnpkg.com/en/docs/cli/install pour obtenir de la documentation sur cette commande.

Le même problème a commencé à se produire aujourd'hui pour l'un de nos projets open source.

Vous pouvez voir une compilation défaillante ici:
https://travis-ci.com/quid/refraction/builds/103692106

Et celui qui réussit (avec --network-concurrency 1 ) ici:
https://travis-ci.com/quid/refraction/builds/103693682

J'espère que cela peut aider à diagnostiquer le problème!

Le code source du référentiel est à:
https://github.com/quid/refraction

Peut-être que cela aide quelqu'un:
Sur notre CI Jenkins, le problème était que Jenkins déclenche des builds parallèles pour nos applications, ce qui signifie que deux (ou plus) scripts shell ont déclenché "yarn install" en même temps, où l'un des processus de build a en outre _supprimé le cache yarn complètement_ (en utilisant "yarn cache clean") avant de lancer "yarn install". C'était bien sûr un problème fatal pour les autres procédés de filage.
Nous avons ensuite supprimé le nettoyage du cache et changé la commande yarn en
yarn install --verbose --prefer-offline --mutex file:/tmp/.yarn-mutex --network-concurrency 1
(_-- verbose_ n'est pas vraiment nécessaire) et inséré
child-concurrency 1
dans .yarnrc.
Maintenant, lorsque les constructions parallèles sont déclenchées, le fil a détecté qu'un autre processus de fil est actif et a attendu qu'il se termine. Cela a résolu les problèmes "aucun fichier de ce type" sur notre CI.

J'obtiens ce problème sur ma machine locale chaque fois que j'utilise une référence de package avec ce format:

"connect-js-adapter-tls": "git+https://github.com/jeremyjs/connect-js-adapter-tls.git#v3.2.2",

Caractéristiques notables: package privé, url github, git + https, référence git balisée

Des étapes qui se reproduisent pour moi:

1. Clean slate: supprimez toutes ces références et exécutez yarn install . Ça fonctionne bien.
2. Ajoutez toutes ces références à mon package.json et exécutez à nouveau yarn install , cela fonctionne toujours bien lors de la première exécution une fois ces références ajoutées.
3. Exécuter yarn install fois supplémentaires après cela fonctionne tant qu'il n'y a pas de changement.
4. Cependant, modifiez tous les packages et exécutez yarn install et j'obtiens l'erreur.
5. Si je supprime ensuite tous ces paquets et exécute yarn install je n'obtiens pas l'erreur. Cela nous ramène à l'étape 1.

L'erreur ressemble à ceci:

error An unexpected error occurred: "ENOENT: no such file or directory, open '/Users/jeremy/Library/Caches/Yarn/v4/npm-connect-js-adapter-tls-3.2.2-0c97726d92c21183a7fb7334344eb5047e8bc158/node_modules/connect-js-adapter-tls/.yarn-metadata.json'".

Si je supprime toutes les références de balises git, j'observe le même comportement. Je pense donc que cela ne peut pas être le problème.
c'est à dire

"connect-js-adapter-tls": "git+https://github.com/jeremyjs/connect-js-adapter-tls.git",

Lancer npm install donne également une erreur:

npm ERR! premature close

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/jeremy/.npm/_logs/2019-03-20T04_38_38_739Z-debug.log

npm-debug.log: https://gist.github.com/jeremyjs/e97381b16f46124ff7a9bd75ad79fd62

En guise de suivi, j'ai utilisé une solution de contournement consistant à créer un script package.json pour nettoyer ces paquets de mon cache avant l'installation:

"install-clean": "yarn cache clean connect-js-adapter-tls connect-js-api connect-js-codec connect-js-encode-decode connect-protobuf-messages && yarn install"

Y a-t-il encore une idée de ce que pourrait être ce problème?
Dans notre cas, nous exécutons yarn install dans le cadre de notre CI (à l'intérieur du conteneur docker) et obtenons ces mêmes erreurs. Nous avons essayé yarn cache clean

Je ne sais pas quoi essayer d'autre à ce stade et cela arrête nos builds. 😬

Dan, avez-vous essayé de courir avec --network-concurrency 1? J'ai un semblable
scénario et cela a résolu mon problème.
Le 2 avril 2019 à 22h17, "Dan Van Brunt" [email protected] a écrit:

Y a-t-il encore une idée de ce que pourrait être ce problème?
Dans notre cas, nous exécutons l'installation de fil dans le cadre de notre CI (inside docker
container) et obtenir ces mêmes erreurs. Nous avons essayé de nettoyer le cache de fil

Je ne sais pas quoi essayer d'autre à ce stade et cela arrête nos builds. 😬

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/yarnpkg/yarn/issues/2629#issuecomment-479283590 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AFU4O1iKA-HBd62Hema1ETmuUlMro_GLks5vdAEOgaJpZM4L3JbX
.

@tevaum qui a également résolu le problème de notre CI. Cela a également considérablement ralenti nos builds. Si terrible, mais seulement une solution de contournement.

Ouais. C'est un mauvais inconvénient. Vous pouvez essayer avec de petits nombres comme 2 ou 4 ...
sera un peu plus rapide, mais pour moi, la seule valeur qui a fonctionné était 1: /

Nous devrons donc attendre que la vraie solution soit heureuse;)
Le 4 avril 2019 00:26, "kunokdev" [email protected] a écrit:

@tevaum https://github.com/tevaum qui a également résolu le problème de notre CI.
Cela a également considérablement ralenti nos builds. Si terrible.

-
Vous recevez cela parce que vous avez été mentionné.

Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/yarnpkg/yarn/issues/2629#issuecomment-479735791 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AFU4O1a9lHn41K0eEQT9zZZzOoATiT61ks5vdXD8gaJpZM4L3JbX
.

Cela sera-t-il jamais réglé? Cela a rendu le fil inutilisable sur plus d'un de mes projets

Veuillez utiliser l'option mutex, documentée ici: https://yarnpkg.com/en/docs/cli/#toc -concurrency-and-mutex

L'utilisation du cache de Yarn n'est pas sûre à utiliser de manière multi-processus et c'est la raison de ces erreurs.

Vous pouvez également définir un dossier de cache par processus à l'aide de l'option --cache-folder documentée ici: https://yarnpkg.com/en/docs/cli/cache#change -the-cache-path-for-yarn-

L'inconvénient de l'utilisation de l'option mutex est de n'avoir qu'une seule instance de fil dans toute la machine (les autres attendront jusqu'à ce que le processus actif se termine), ce qui signifie aucune concurrence entre les travaux CI.

L'inconvénient d'un dossier de cache par processus est une augmentation des E / S et une perte de potentiel en raison d'une moindre réutilisation du cache.

La solution idéale serait d'implémenter une implémentation de cache sécurisée pour les processus, ce qui n'est pas très facile avec le manque de capacités de verrouillage de fichier dans Node (la seule option fiable semble être la création de répertoires mutex). Le deuxième meilleur est d'utiliser un dossier de cache par bras parallèle qui permettrait la concurrence et la réutilisation du cache dans le même bras.

Je ne pense pas que ce soit le truc des mutex. Moi et d'autres exécutons un seul fil à la fois - dans mon cas, c'est juste RUN yarn install dans un Dockerfile - pendant la phase de construction de l'image du docker. Cela garantit qu'aucun autre processus ne s'exécute simultanément dans cet environnement.

Découvrez cet exemple de reproduction minimale (au moins pour mon OSX):

728 22:49:55 iMac ~/tmp/ynse$ ls
Dockerfile  package.json
729 22:49:58 iMac ~/tmp/ynse$ cat Dockerfile
FROM node
ADD . /app
WORKDIR /app
RUN yarn

730 22:50:00 iMac ~/tmp/ynse$ cat package.json
{
  "dependencies": {
    "react-navigation-core": "https://github.com/react-navigation/react-navigation-core",
    "react-navigation-hooks": "https://github.com/react-navigation/react-navigation-hooks"
  }
}
731 22:50:03 iMac ~/tmp/ynse$ docker build -t yt .
Sending build context to Docker daemon  15.87kB
Step 1/4 : FROM node
 ---> 39337023f8d4
Step 2/4 : ADD . /app
 ---> aa86b2d7f191
Step 3/4 : WORKDIR /app
 ---> Running in 83baa8603935
Removing intermediate container 83baa8603935
 ---> 80741f170292
Step 4/4 : RUN yarn
 ---> Running in 0718118bdcd6
yarn install v1.3.2
warning package.json: No license field
info No lockfile found.
warning No license field
[1/4] Resolving packages...
[2/4] Fetching packages...
[1/4] Resolving packages...
[2/4] Fetching packages...
[1/4] Resolving packages...
[2/4] Fetching packages...
info If you think this is a bug, please open a bug report with the information provided in "/app/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
error An unexpected error occurred: "https://registry.yarnpkg.com/lodash/-/lodash-4.17.11.tgz: EEXIST: file already exists, mkdir '/usr/local/share/.cache/yarn/v1/npm-lodash-4.17.11-b39ea6229ef607ecd89e2c8df12536891cac9b8d'".
^C
732 22:50:23 iMac ~/tmp/ynse$

@nopik - Yarn 1.3.2 est très ancien et il y a eu de nombreuses corrections après cette version. Avez-vous essayé d'utiliser l'une des dernières versions de Docker?

En effet, cette image de nœud était assez ancienne. En voici un nouveau téléchargé il y a quelques minutes à partir du nœud dockerhub

Sending build context to Docker daemon  15.87kB
Step 1/4 : FROM node
 ---> a9c1445cbd52
Step 2/4 : ADD . /app
 ---> Using cache
 ---> 26ed37136c09
Step 3/4 : WORKDIR /app
 ---> Using cache
 ---> b2339e7d25af
Step 4/4 : RUN yarn
 ---> Running in cdbdfd9c373c
yarn install v1.15.2
warning package.json: No license field
info No lockfile found.
warning No license field
[1/4] Resolving packages...
[2/4] Fetching packages...
[1/4] Resolving packages...
[2/4] Fetching packages...
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "ENOTEMPTY: directory not empty, rmdir '/usr/local/share/.cache/yarn/v4/npm-lodash-4.17.11-b39ea6229ef607ecd89e2c8df12536891cac9b8d/node_modules/lodash'".
info If you think this is a bug, please open a bug report with the information provided in "/app/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

@BYK Avez-vous essayé de créer ce docker vous-même?

J'essaierai dans quelques jours une fois que j'arriverai à mon ordinateur (sur mobile maintenant). Ça a l'air très bizarre mais le répertoire est cohérent. Je vais essayer de voir ce qui se passe, merci pour le cas de repro.

@nopik - en regardant de plus près le journal, il montre en effet plusieurs instances de Yarn s'exécutant en parallèle. Vous ne devriez jamais voir le même message «Résolution des packages» deux fois. Je ne sais pas pourquoi cela se produit, mais je suis sûr à 100% que c'est la raison.

@BYK Je vois que l'un de ces paquets a "scripts": { "build": "yarn babel --out-dir dist && del-cli 'dist/**/__tests__' && yarn tsc --emitDeclarationOnly", "prepare": "yarn build" } l'autre a des scripts différents, mais toujours en cours d'exécution yarn dans prepare .. Sont-ils lancés par yarn pendant l'installation?

@Nopik - ne pensez pas que cela causerait le problème car ils exécutent simplement des scripts, pas une autre installation. Ces scripts sont également exécutés après la phase d'E / S. Il doit y avoir quelque chose d'autre déclenchant plusieurs instanaces yarn install .

Je conviens que ce sont probablement plusieurs instances de fil qui fonctionnent simultanément. Le problème est que cela se produit sur une seule invocation cli de yarn . Cela n'a pas besoin de docker pour se reproduire.

Ma théorie, certes sous-informée, est que c'est quelque chose lié à l'étape de préparation et que yarn pourrait lancer une instance supplémentaire pour "construire" des packages git. En particulier, je parie que ce sont deux dépendances qui dépendent chacune d'un paquet commun qui doit également être construit. Yarn essaie d'être intelligent et de construire chaque package séparé en parallèle, mais échoue lorsqu'il tente de créer deux packages dans le même emplacement de cache.

Dans notre cas, nous n'avons pas plusieurs instances de fils.

Notre système fonctionne dans sa propre image de docker. Il a un seul _ installation de fil _. Tout à coup, il a commencé à mal se comporter et nous ne pouvons plus travailler sans que la concurrence réseau soit définie sur 1.
À moins que le fil lui-même ait changé pendant la nuit, je ne vois pas d'autre problème que le fait que le fil se pose lui-même avec des conditions spécifiques.

Si vous essayez de résoudre ce problème avec --mutex file ou même --mutex network , vous rencontrerez inévitablement (probablement) ce bogue https://github.com/yarnpkg/yarn/issues/6650 (ouvert / non résolu depuis 6 mois maintenant) 😢

Ce qui signifie qu'une fois que vous exécutez yarn install , bien que cela réussisse, vous ne pourrez jamais exécuter une autre commande de fil

Dan, avez-vous essayé de courir avec --network-concurrency 1? J'ai un scénario similaire et cela a résolu mon problème.

@tevaum - C'était exactement le problème. MERCI!
J'avais un script que je ne pensais pas exécuter plus d'une instance, mais c'était le cas. 🤦‍♂️

@tevaum a aussi résolu pour moi. Je vous remercie.

Si vous essayez de résoudre ce problème avec le fichier --mutex ou même le réseau --mutex, vous rencontrerez inévitablement (probablement) ce bogue # 6650 (ouvert / non résolu depuis 6 mois maintenant)

@sarink - J'ai aussi rencontré le bogue de l'option mutex; Merci de l'avoir mentionné.

yarn dit que tout va bien.

PS C:\Users\chtacklind\Desktop\git\Project> yarn --verbose
yarn install v1.10.1
verbose 0.282 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.284 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.285 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 0.286 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\npmrc".
verbose 0.288 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.289 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.29 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\.npmrc".
verbose 0.291 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\.npmrc".
verbose 0.295 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 0.297 Checking for configuration file "C:\\Users\\.npmrc".
verbose 0.3 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.301 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.302 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.309 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.312 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\yarnrc".
verbose 0.317 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.318 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.319 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\.yarnrc".
verbose 0.326 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\.yarnrc".
verbose 0.327 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.333 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.336 Checking for configuration file "C:\\Users\\.yarnrc".
verbose 0.346 current time: 2019-05-12T11:56:12.800Z
[1/4] Resolving packages...
success Already up-to-date.
Done in 0.33s.

Pourtant, l'exécution de yarn --check tente de construire mais échoue toujours.

Parfois avec des messages d'erreur déformés à la fin:

PS C:\Users\chtacklind\Desktop\git\Project> yarn --check-files --network-concurrency 1 --mutex file:C:/.yarn-mutex --verbose
yarn install v1.10.1
verbose 0.286 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.288 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.289 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 0.29 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\npmrc".
verbose 0.291 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.292 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.293 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\.npmrc".
verbose 0.294 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\.npmrc".
verbose 0.295 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 0.296 Checking for configuration file "C:\\Users\\.npmrc".
verbose 0.302 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.304 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.305 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.306 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.307 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\yarnrc".
verbose 0.308 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.311 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.313 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\.yarnrc".
verbose 0.314 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\.yarnrc".
verbose 0.315 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.316 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.317 Checking for configuration file "C:\\Users\\.yarnrc".
verbose 0.32 current time: 2019-05-12T11:56:20.033Z
[1/4] Resolving packages...
[2/4] Fetching packages...
verbose 2.344 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\ef8122f161347726dd1763e1dca6eeef.d34344cbdf2ff518a03c08fc5f46827c9d66e543.prepare\\.npmrc".
verbose 2.344 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 2.345 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\npmrc".
verbose 2.345 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\ef8122f161347726dd1763e1dca6eeef.d34344cbdf2ff518a03c08fc5f46827c9d66e543.prepare\\.npmrc".
verbose 2.346 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\.npmrc".
verbose 2.346 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.npmrc".
verbose 2.346 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\.npmrc".
verbose 2.346 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\.npmrc".
verbose 2.347 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\.npmrc".
verbose 2.347 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\.npmrc".
verbose 2.347 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 2.348 Checking for configuration file "C:\\Users\\.npmrc".
verbose 2.348 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\ef8122f161347726dd1763e1dca6eeef.d34344cbdf2ff518a03c08fc5f46827c9d66e543.prepare\\.yarnrc".
verbose 2.349 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 2.35 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 2.351 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\yarnrc".
verbose 2.352 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\ef8122f161347726dd1763e1dca6eeef.d34344cbdf2ff518a03c08fc5f46827c9d66e543.prepare\\.yarnrc".
verbose 2.353 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\.yarnrc".
verbose 2.358 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.yarnrc".
verbose 2.359 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\.yarnrc".
verbose 2.36 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\.yarnrc".
verbose 2.361 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\.yarnrc".
verbose 2.362 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\.yarnrc".
verbose 2.363 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 2.364 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 2.366 Checking for configuration file "C:\\Users\\.yarnrc".
[1/4] Resolving packages...
[2/4] Fetching packages...
verbose 2.541 Performing "GET" request to "https://registry.yarnpkg.com/typescript/-/typescript-3.3.3333.tgz".
verbose 3.263 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc8.09d44d8abc94f728f1c5ea93c22fe9b4f87d9076.prepare\\.npmrc".
verbose 3.264 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 3.265 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\npmrc".
verbose 3.266 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc8.09d44d8abc94f728f1c5ea93c22fe9b4f87d9076.prepare\\.npmrc".
verbose 3.268 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\.npmrc".
verbose 3.27 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.npmrc".
verbose 3.271 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\.npmrc".
verbose 3.273 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\.npmrc".
verbose 3.278 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\.npmrc".
verbose 3.279 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\.npmrc".
verbose 3.28 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 3.281 Checking for configuration file "C:\\Users\\.npmrc".
verbose 3.283 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc8.09d44d8abc94f728f1c5ea93c22fe9b4f87d9076.prepare\\.yarnrc".
verbose 3.285 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 5.007 Error: https://registry.yarnpkg.com/typescript/-/typescript-3.3.3333.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, stat 'C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\npm-typescript-3.3.3333-171b2c5af66c59e9431199117a3bcadc66fdcfd6\\lib\\tsserver.js'"nd\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc
    at MessageError.ExtendableBuiltin (C:\Program Files (x86)\Yarn\lib\cli.js:243:66)
    at new MessageError (C:\Program Files (x86)\Yarn\lib\cli.js:272:123)pData\\Local\\Yarn\\Cache\\v2\\.tmp\\.yarnrc".
    at Extract.<anonymous> (C:\Program Files (x86)\Yarn\lib\cli.js:56849:14)a\\Local\\Yarn\\Cache\\v2\\.yarnrc".
    at Extract.emit (events.js:194:15)on file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\.yarnrc".
    at Extract.module.exports.Extract.destroy (C:\Program Files (x86)\Yarn\lib\cli.js:131115:17)nrc".
    at onunlock (C:\Program Files (x86)\Yarn\lib\cli.js:130992:26)nd\\AppData\\Local\\.yarnrc".
    at C:\Program Files (x86)\Yarn\lib\cli.js:43373:25rs\\chtacklind\\AppData\\.yarnrc".
    at C:\Program Files (x86)\Yarn\lib\cli.js:43339:23rs\\chtacklind\\.yarnrc".
    at C:\Program Files (x86)\Yarn\lib\cli.js:56799:13acklind\\.yarnrc".
    at FSReqWrap.oncomplete (fs.js:153:21)ile "C:\\Users\\.yarnrc".
error https://registry.yarnpkg.com/typescript/-/typescript-3.3.3333.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, stat 'C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\npm-typescript-3.3.3333-171b2c5af66c59e9431199117a3bcadc66fdcfd6\\lib\\tsserver.js'"
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
PS C:\Users\chtacklind\Desktop\git\Project>

Parfois avec des erreurs différentes:

...
[2/4] Fetching packages...
verbose 2.635 Performing "GET" request to "https://registry.yarnpkg.com/typescript/-/typescript-3.3.3333.tgz".
verbose 3.465 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc8.09d44d8abc94f728f1c5ea93c22fe9b4f87d9076.prepare\\.npmrc".
verbose 3.466 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 3.467 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\npmrc".
verbose 3.468 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc8.09d44d8abc94f728f1c5ea93c22fe9b4f87d9076.prepare\\.npmrc".
verbose 3.469 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\.npmrc".
verbose 3.47 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.npmrc".
verbose 3.471 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\.npmrc".
verbose 3.473 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\.npmrc".
verbose 3.474 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\.npmrc".
verbose 3.48 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\.npmrc".
verbose 3.481 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 3.482 Checking for configuration file "C:\\Users\\.npmrc".
verbose 3.483 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc8.09d44d8abc94f728f1c5ea93c22fe9b4f87d9076.prepare\\.yarnrc".
verbose 3.485 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 3.486 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 3.49 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\yarnrc".
verbose 3.492 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc8.09d44d8abc94f728f1c5ea93c22fe9b4f87d9076.prepare\\.yarnrc".
verbose 3.493 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\.yarnrc".
verbose 3.494 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.yarnrc".
verbose 3.495 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\.yarnrc".
verbose 3.496 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\.yarnrc".
verbose 3.497 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\.yarnrc".
verbose 3.501 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\.yarnrc".
verbose 3.503 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 3.504 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 3.505 Checking for configuration file "C:\\Users\\.yarnrc".
[1/4] Resolving packages...
[2/4] Fetching packages...
verbose 4.608 Error: EPERM: operation not permitted, unlink 'C:\Users\chtacklind\AppData\Local\Yarn\Cache\v2\npm-typescript-3.3.3333-171b2c5af66c59e9431199117a3bcadc66fdcfd6\.yarn-tarball.tgz'
error An unexpected error occurred: "EPERM: operation not permitted, unlink 'C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\npm-typescript-3.3.3333-171b2c5af66c59e9431199117a3bcadc66fdcfd6\\.yarn-tarball.tgz'".
info If you think this is a bug, please open a bug report with the information provided in "C:\\Users\\chtacklind\\Desktop\\git\\Project\\yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
PS C:\Users\chtacklind\Desktop\git\Project>

Notez que deux processus de fil sont en cours d'exécution même si j'ai spécifié --mutex .

Il est à noter que ce paquet a une dépendance git qui a une étape tsc prepare qui doit être effectuée. Ce package a également une dépendance git qui nécessite le même processus. Il est clair que le fil essaie de déballer le même paquet au même endroit et nous obtenons une condition de course.

Pourquoi yarn exécute-t-il plusieurs instances même lorsqu'on lui dit de ne pas le faire?

En tant que mise à jour, l'utilisation de yarn install --network-concurrency 1 --mutex network semble fonctionner à chaque fois où l'utilisation de l'une ou l'autre des options a tendance à ne réussir qu'une partie du temps.

Alors, quelle est la résolution de ce problème?
J'utilise yarn 1.16 sur Ubuntu Linux 18.04
Et je reçois toujours ce message d'erreur:

erreur Une erreur inattendue s'est produite: "ENOENT: aucun fichier ou répertoire de ce type, lstat '/ home / user / workspace / project / packages / components / node_modules / source-map-support'".

Ma commande est:

yarn install --check-files --frozen-lockfile --network-concurrency 1

Et j'obtiens cette erreur une fois sur deux: ((
PS: je travaille dans monorepo donc j'ai activé les espaces de travail de fil
PPS:
J'ai vérifié
L'ajout d'un fichier --mutex ou d'un réseau --mutex n'aide pas.

La seule solution que je peux confirmer que fonctionne est de mettre un script

until
    yarn install --check-files --frozen-lockfile;
do
    echo "Surprise, surprise. Let's try again..."
done

:(

Fwiw, j'ai pu passer à npm en ne faisant rien de plus qu'une recherche / remplacement de yarn avec npm , en utilisant synp pour convertir yarn.lock en package-lock.json , et exécutez npm install . Je pensais que ce serait un processus douloureux, mais npm a beaucoup avancé et cela ne m'a pris qu'environ 30 minutes et maintenant ça marche partout

Il semble que le problème ici est qu'il n'y a pas d'exemple vraiment simple de ce qui ne va pas. J'ai posté un simple package.json qui reproduit de manière fiable le problème pour moi, mais les packages inclus sont quelque peu compliqués.

Je soupçonne que le problème est lorsque vous avez une arborescence de dépendances avec des «feuilles» / astuces partagées qui prennent du temps à compiler / installer (préparer) et que le fil essaie de le faire deux fois, en même temps. Chaque instance est «préparée» dans un emplacement prévisible partagé et ils ne peuvent pas tous les deux «écrire» au même emplacement en même temps (l'un supprime un fichier tandis que l'autre s'attend à ce qu'il soit toujours là).

J'avais l'intention de créer des packages simples de preuve de concept avec des étapes de «préparation» gonflées pour tester cette théorie mais je n'ai pas eu le temps. Peut-être que quelqu'un d'autre peut tester cette théorie avant d'y arriver?

Cela se produit lorsque plusieurs instances de yarn sont exécutées simultanément. Vous pouvez utiliser l'option --mutex documentée ici: https://yarnpkg.com/en/docs/cli/#toc -concurrency-and-mutex

@BYK Il semble qu'il y ait de nombreux cas où ce n'est pas le problème. D'autres ont même indiqué que cette option leur posait d'autres problèmes.

@cinderblock # 6650 semble être un cas limite et ne devrait pas vraiment affecter la résolution de ce problème. L'autre exemple que vous mentionnez est que le fil est toujours déclenché en mode d'installation lors d'une autre installation, ce qui est probablement un package problématique car vous ne devriez pas déclencher une autre installation pendant l'installation de votre package. Cela peut également être évité par --ignore-scripts qui est également recommandé.

Si vous avez d'autres pistes, merci de les partager afin que quelqu'un puisse, espérons-le, passer plus de temps à le déboguer.

@BYK Je n'ai vu personne utiliser intentionnellement yarn install dans un script install . Avez-vous vu ce trivial package.json qui produit ce problème? Certes, c'est quelque chose dans les packages dépendants qui provoque cette erreur, et peut-être qu'ils ont un install enterré auquel vous faites référence. Cependant, package.json fonctionne très bien avec npm ...

En relation, comment / où est-il recommandé de --ignore-scripts ? De nombreux packages reposent sur des scripts de post-installation pour fonctionner.

En relation, comment / où est-il recommandé --ignore-scripts? De nombreux packages reposent sur des scripts de post-installation pour fonctionner.

Oh, je l'ai juste recommandé ici et je pense que de nombreux membres de Yarn en ont parlé. 😀 La plupart des paquets sont bons mais il y a en effet quelques paquets qui reposent sur des scrpits post-installation ouais.

Avez-vous vu ce package.json trivial

Oui, mais même un fichier package.json "trivial" peut donner lieu à un très grand arbre de dépendances, donc dire qu'il est trivial, cela ne change pas vraiment beaucoup sauf que j'ai tendance à l'interpréter de l'une des manières suivantes:

• le fil est trop merdique donc il ne peut même pas gérer ce fichier _trivial_ package.json
• ce problème peut être reproduit avec un fichier _trivial_ package.json, mais vous ne pouvez toujours pas / ne le résolvez pas

là où aucun de ceux-ci n'est utile, j'ai donc tendance à ignorer votre commentaire.

Pour le problème réel, pour que yarn fonctionne avec le mutex, toutes les instances de yarn doivent être appelées avec l'indicateur --mutex donc la meilleure façon de voir si cela résout le problème est d'ajouter --install.mutex network à votre .yarnrc fichier (voir https://yarnpkg.com/en/docs/yarnrc#toc-cli-arguments). Cela dit, cela peut conduire à un blocage si l'installation initiale déclenche une autre installation, où la deuxième installation attendra la fin de la principale et la principale sera bloquée sur ce fil invoqué par script pour terminer, donc je ne le fais pas vraiment savoir comment résoudre ce problème autre que l'implémentation d'un système de cache thread / process-safe, ce qui est presque impossible avec les primitives de verrouillage fournies par node . La chose la plus proche semble être ce package de verrouillage approprié , mais aucun de nous n'a eu le temps de l'essayer. Je peux vous aider si vous souhaitez essayer d'implémenter cela dans le code d'écriture / lecture du cache.

@BYK Oh, mes excuses si je suis parti comme ça. Je n'avais pas vu de moyen de reproduire de manière fiable l'erreur avant cela, même si elle n'est toujours pas suffisamment distillée pour résoudre le problème. C'était tout mon élan pour ce commentaire.

Pardonnez ma persévérance mais je ne vois toujours pas en quoi l'option mutex est une solution. J'ai essayé de courir avec mutex et il fonctionnait toujours en même temps. Peut-être ai-je fait une erreur lors de mes tests ? Je m'attendais à ce que l'exécution de yarn --mutex ... transmette cette option aux instances enfants (comme le fait make , par exemple). J'ai également essayé votre suggestion d'ajouter --install.mutex network à mon fichier .yarnrc en vain (mêmes erreurs). --verbose confirme que les options sont en cours de chargement.

Peut-être pourrions-nous arriver à cela d'une autre direction? Que fait le fil que npm ne fait pas? Pourquoi npm n'a-t-il pas ce même problème?

@BYK , utiliser le drapeau mutex est totalement inacceptable, car il y a un bug de fil supplémentaire qui vous empêchera alors de _ jamais exécuter une autre commande de fil _... C'est comme si votre solution à "J'ai verrouillé mes clés dans ma voiture "était," ne vous inquiétez pas, j'y ai pensé! Utilisez simplement cet outil pratique pour enfoncer toutes vos fenêtres et serrures de portes, maintenant vous ne pourrez plus jamais verrouiller votre voiture! " 🙄

Trivial package.json ou pas, c'est un gros problème sans solution ou contournement qui rend le fil complètement inutilisable pour beaucoup de gens. Cela devrait attirer plus d'attention. Surtout compte tenu du fait qu'il est ouvert depuis _deux ans_.

@sarink

@BYK , l'utilisation de l'indicateur mutex est totalement inacceptable, car il y a un bug de fil supplémentaire qui vous empêchera alors d'exécuter une autre commande de fil ...

Je ne suis pas au courant d'un tel bug, pouvez-vous me le signaler s'il est déjà signalé? La façon dont --mutex fonctionne est d'empêcher toute autre instance yarn utilisant le même mutex de s'exécuter, jusqu'à ce que l'initialisation se termine. Donc, ce que vous dites (pas votre représentation) me semble "fonctionne comme prévu".

Trivial package.json ou pas, c'est un gros problème sans solution ou contournement qui rend le fil complètement inutilisable pour beaucoup de gens. Cela devrait attirer plus d'attention. D'autant plus qu'il est ouvert depuis deux ans.

Peut-être devriez-vous prendre une minute pour réfléchir à la contradiction interne de votre propre phrase: «rend le fil complètement inutilisable pour beaucoup de gens» et «il est ouvert depuis deux ans». Il n'y a que 56 participants à ce numéro, qui comprend ~ 5 mainteneurs de fil et un total de 138 commentaires, la plupart tournant autour des mêmes choses. Ce n'est pas "beaucoup de gens", ce sont des gens et c'est sûr que c'est important pour eux, mais je vois qu'aucun d'eux ne prend cela aussi important d'envoyer une seule ligne de correctif de code et d'exiger simplement des correctifs pour un logiciel entièrement fourni gratuit pour eux.

@cinderblock

Pardonnez ma persévérance mais je ne vois toujours pas en quoi l'option mutex est une solution.

Rien à pardonner en ce qui concerne la persévérance, il faut en fait le célébrer car vous essayez de résoudre le problème :)

Je m'attendais à ce que l'exécution de yarn --mutex ... transmette cette option aux instances enfants (comme make does, par exemple).

Je suis convaincu que ce n'est pas transmis.

J'ai également essayé votre suggestion d'ajouter le réseau --install.mutex à mon fichier .yarnrc en vain (mêmes erreurs). --verbose confirme que les options sont en cours de chargement.

C'est assez intéressant. C'est peut-être parce que la nouvelle instance de fil est déclenchée depuis un autre répertoire, ignorant votre fichier .yarnrc . Je peux suggérer d'utiliser un fichier global .yarnrc avec cette option, cela dit que je ne pense pas que ce soit une solution appropriée. Nous ne devrions essayer cela que pour voir si cela bloque réellement l'installation comme prévu précédemment.

Peut-être pourrions-nous arriver à cela d'une autre direction? Que fait le fil que npm ne fait pas? Pourquoi npm n'a-t-il pas ce même problème?

J'apprécie la diversité de la pensée, qui dit que Yarn et npm sont si différents dans leur façon de fonctionner, je ne pense pas que cela s'applique vraiment ici. Si nous pouvons identifier quel package déclenche une installation de fil dans le cadre de leur propre installation, nous pouvons trouver une solution. Peut-être pouvez-vous remplacer l'exécutable yarn par un script bash qui enregistre la source d'appel, cwd et tous les arguments passés, puis exécute yarn comme d'habitude pour obtenir des informations de débogage utiles et continuer à partir de là?

La solution ultime serait une implémentation de cache conviviale comme je l'ai mentionné précédemment, mais avec plus d'informations de débogage, nous pourrons peut-être trouver une solution de contournement moins chère.

Merci beaucoup pour votre coopération avec ce @cinderblock , très apprécié.

La solution ultime serait une implémentation de cache conviviale comme je l'ai mentionné précédemment, mais avec plus d'informations de débogage, nous pourrons peut-être trouver une solution de contournement moins chère.

Je suppose qu'il devrait être possible de fournir une gestion simplifiée de la concurrence - par exemple, si d'autres instances de fil sont appelées pendant l'étape de construction, il devrait y avoir très peu d'opérations de cache par le processus de fil supérieur. Du moins, c'est ce à quoi je m'attendais. S'assurer que le cache est vidé sur le disque avant d'appeler d'éventuels scripts peut faire l'affaire. Je ne sais pas quelle est la complexité de la mise en œuvre

@BYK Oh! Je n'avais pas envisagé la possibilité qu'un sous-paquet appelle yarn ... dans un script. Pensez-vous que la raison npm install laquelle yarn ... il n'y a qu'une seule instance en cours d'exécution?

j'ai réussi à résoudre le problème de la course

yarn cache clean
rm ./yarn.lock
yarn install

Ce processus, cependant, prend du temps, car il télécharge à nouveau tous les packages car vous a) n'avez plus de cache et votre fichier de verrouillage a été supprimé.

Cela pourrait résoudre sur votre machine locale, mais le problème avec le fil persiste au cas où il serait utilisé sur Bitrise. C'est une image propre, à partir de zéro. La concurrence réseau est requise dans tous les cas, même lorsqu'un processus de fil unique est en cours d'exécution.

@BYK

Il n'y a que 56 participants à ce numéro, qui comprend ~ 5 mainteneurs de fil et un total de 138 commentaires, la plupart tournant autour des mêmes choses.

Cela semble être un nombre assez élevé pour ce repo. C'est le total de commentaires le plus élevé parmi tous les problèmes ouverts et fermés, et c'est l'un des plus grands nombres de participants.

Quoi de plus, en recherchant un problème (probablement) lié, j'ai vu pas mal de personnes avec des problèmes qui étaient probablement liés. Le malheur est que beaucoup de ces personnes ont soit abandonné le fil dans son ensemble, soit avalé le coût de --network-cocurrency 1 chaque fois que le fichier de verrouillage de fil changeait. C'est exactement ce que je faisais pour l'un de mes projets jusqu'à ce que je comprenne enfin qu'il s'agissait d'un sous-script.

Ce n'est pas "beaucoup de gens", il s'agit de certaines personnes et c'est sûr que c'est important pour eux, mais je vois qu'aucun d'entre eux ne prend cela aussi important d'envoyer une seule ligne de correctif de code et d'exiger simplement des correctifs pour un logiciel entièrement fourni gratuit pour eux.

Yarn n'est pas le type de projet dans lequel les gens peuvent facilement se lancer. C'est un système complexe qui fait beaucoup de choses de manière asyncrone, ce qui signifie que vous ne pouvez pas simplement placer un débogueur et remonter la pile pour voir ce qui se passe. En tant que tel, il n'est en aucun cas facile de comprendre cette base de code, et il est encore plus difficile de la modifier. Bon sang, à ce stade, j'ai déjà passé quelques jours de temps cumulatif à lire le code, et je ne me sens toujours pas assez en confiance pour soumettre même un simple patch avec des tests pertinents. Étant donné que je suis assis sur plus de deux décennies d'expérience et que la lecture de code est l'une de mes spécialités, je ne donnerais pas les meilleures chances à un développeur moyen.

En d'autres termes, ce qui peut être une solution rapide et simple en une seule ligne pour vous peut être un gros projet de plusieurs jours pour quelqu'un qui n'est pas familier avec le fonctionnement interne du projet. C'est avant que je mentionne les politiques implicites qui existent dans diverses communautés. J'ai eu au moins quelques PR refusés dans divers projets open source parce que je n'ai pas suivi un protocole, ou écrit le bon test, obéi aux bonnes spécifications, ou même simplement pour avoir un correctif non conforme à certaines normes de codage non documentées. Cela peut être un défi de contribuer de manière significative à de grands projets en tant qu'étranger.

Si c'est vraiment un correctif sur une seule ligne pour vous, ne serait-il pas plus rapide d'écrire ce correctif au lieu d'écrire un long article critiquant les autres pour ne pas le faire?

Si nous pouvons identifier quel package déclenche une installation de fil dans le cadre de leur propre installation, nous pouvons trouver une solution.

J'ai un exemple de package qui présente ce type de comportement ici , bien que je ne vois pas de yarn install là-dedans (à moins que le bob build fasse, bien qu'il ait également montré ce problème quand la commande était "prepare": "node ./scripts/generate-mappings", ).

La solution ultime serait une implémentation de cache conviviale comme je l'ai mentionné précédemment, mais avec plus d'informations de débogage, nous pourrons peut-être trouver une solution de contournement moins chère.

Un bon point de départ serait un avertissement si une telle situation est détectée (en supposant qu'elle est détectable). Un cache convivial pour la concurrence semble devoir être un effort concentré d'au moins un membre de la communauté du fil.

La mise à jour a trouvé une solution de contournement qui fonctionne ... un sous-module git, puis l'emplacement du package doit être le dossier local. Pas idéal, mais ça marche.

Nous avons aussi ce problème dans CircleCI et c'est un gros problème. Le problème semble être lié à l'utilisation d'un package hébergé sur github.com et peut-être Linux (cela fonctionne sous OSX). mutex options network-concurrency ne font rien.

"my-js-lib": " ssh: //[email protected] : dgobaud / my-js-ib # 1.0.0"

si je supprime que cela fonctionne dans CircleCI. Localement, il fonctionne avec sur OSX avec du fil 1.17.0.

Mais cela ne fonctionnera pas sur CircleCI avec le nœud 12.8.1 et le fil 1.17.3 (image du cercle circleci / nœud: dernier)

Ou avec Node 8.15.0 et yarn 1.12.3 (cercle image circleci / node: 8.15.0)

#!/bin/bash -eo pipefail
yarn install --mutex network --network-concurrency 1
yarn install v1.12.3
[1/4] Resolving packages...
warning Resolution field "[email protected]" is incompatible with requested version "mixin-deep@^1.2.0"
warning Resolution field "[email protected]" is incompatible with requested version "set-value@^2.0.0"
warning Resolution field "[email protected]" is incompatible with requested version "set-value@^0.4.3"
[2/4] Fetching packages...
info [email protected]: The platform "linux" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
$ cd functions && yarn install
yarn install v1.12.3
[1/5] Validating package.json...
[2/5] Resolving packages...
warning Resolution field "[email protected]" is incompatible with requested version "mixin-deep@^1.2.0"
warning Resolution field "[email protected]" is incompatible with requested version "set-value@^2.0.0"
warning Resolution field "[email protected]" is incompatible with requested version "set-value@^2.0.1"
[3/5] Fetching packages...
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
error https://registry.yarnpkg.com/lodash/-/lodash-4.17.15.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, chmod '/home/circleci/.cache/yarn/v4/npm-lodash-4.17.15-b447f6670a0455bbfeedd11392eff330ea097548/node_modules/lodash/_arrayReduceRight.js'"
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
info There appears to be trouble with your network connection. Retrying...
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
Exited with code 1

--network-concurrency 1 réussit, --network-concurrency 8 échoue, sur circleCI / node: 10

Quelqu'un peut-il m'aider à comprendre pourquoi Yarn doit échouer sur EEXIST et EOENT?

Dans le cas d'EEXIST, je m'attendrais à ce que Yarn en avertisse, puis remplace le fichier.
Dans le cas de EOENT, je m'attendrais à ce que Yarn crée le dossier manquant (qui est généralement la cause du problème).

Je comprends que cela peut avoir des effets secondaires, alors peut-être que ce comportement pourrait être rendu plus strict avec un drapeau (ou vice-versa).

Mais quel est l'intérêt de garder ces erreurs autour? Ils ne sont utiles à personne.

@BYK Désolé, je viens de voir votre commentaire

Je ne suis pas au courant d'un tel bug, pouvez-vous me le signaler s'il est déjà signalé? La façon dont --mutex fonctionne est d'empêcher toute autre instance yarn utilisant le même mutex de s'exécuter, jusqu'à ce que l'initialisation se termine. Donc, ce que vous dites (pas votre représentation) me semble "fonctionne comme prévu".

C'est le bug: https://github.com/yarnpkg/yarn/issues/6650 comme mentionné dans https://github.com/yarnpkg/yarn/issues/2629#issuecomment -481297806 (qui, je crois, est maintenant enterré sous le "afficher plus d'histoire" dans ce fil)

Il n'y a que 56 participants à ce numéro

Eh bien, je suppose que c'est un bon point

Ce bogue est toujours dans le fil v1.19.1. Je ne comprends pas pourquoi Yarn Team ne répare pas ce bug très gênant.
voici mon .yarnrc et cela n'aide pas:

save-prefix ""
--install.check-files true
--add.check-files true
--remove.check-files true
--install.frozen-lockfile true
--add.frozen-lockfile true
--remove.frozen-lockfile true
--install.mutex network
--install.mutex file

Ce que je viens de découvrir, c'est qu'exécuter npx lerna clean && ./yarn-install-in-loop.sh aide.
Nettoyer (supprimer) tous les répertoires node_modules de mon monorepo aide.

@gitowiec peut confirmer. Mes invocations de yarn install conteneurisées sont des données qui contiennent quelque chose sur le système de fichiers, et chaque tentative de limiter yarn à un seul fichier .yarnrc échoue. J'abandonne et je reviens à npm .

J'ai trouvé que mon problème était d'avoir des dépendances de package à partir de référentiels git à travers plusieurs niveaux (c'est-à-dire mon package -> package git -> package git -> package git). De plus, le cache lors de l'installation ne fonctionnait pas bien par rapport à npm (npm ne vérifiait qu'une seule fois, mais yarn checkout plusieurs fois le même package au cours de la même installation).
Je retourne à npm. Cela fonctionne bien depuis la v6.

A mentionné ci-dessus, ce problème existe toujours. Voici ce que nous avons ajouté à notre config.yml pour que circleci fasse passer nos tests:
- run: name: Yarn Install source ~/setyarnpath.sh i=5; until yarn; do echo "Yarn failed. Retrying..."; ((i--)); if [[ "$i" == '0' ]]; then break; fi; done

J'avais le même problème. Utilisation de macOS et de docker-compose, avec un volume hôte [1] contenant mon code ET node_modules.

Modules node_modules modifiés pour être à l'intérieur d'un volume anonyme , mais je suppose qu'un volume nommé fonctionnerait également. Et cela semble fonctionner correctement maintenant, et aussi installer les dépendances beaucoup plus rapidement.

Mon fichier docker-compose a changé de:

services:
  ...
  web:
    build: .
    volumes:
      - .:/home/example
    ports:
      - "3000:3000"
    ...

À:

services:
  ...
  web:
    build: .
    volumes:
      - .:/home/example
      - /home/example/node_modules
    ports:
      - "3000:3000"
    ...

[1] https://success.docker.com/article/different-types-of-volumes

Je vois une nouvelle erreur avec yarn récente qui, je pense, est un nouveau symptôme de ce problème.

yarn stdout [1/4] Resolving packages...
yarn stdout [2/4] Fetching packages...
yarn stderr error https://registry.yarnpkg.com/prettier/-/prettier-1.19.1.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "EEXIST: file already exists, mkdir '/home/pi/.cache/yarn/v6/npm-prettier-1.19.1-f7d7f5ff8a9cd872a7be4ca142095956a60797cb-integrity/node_modules/prettier'"
yarn stdout info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
yarn stderr Process stalled
yarn stderr Active handles:
yarn stderr   - Socket
yarn stderr   - Socket
yarn stderr   - Socket
yarn stderr   - TLSSocket
yarn stderr   - TLSSocket
yarn stderr   - TLSSocket

Remarque: yarn stderr/out sont le préfixe que mon programme donne à la sortie de yarn dans mon env

Je pense que c'est le même problème car mon projet pourrait créer de manière assez cohérente les anciens symptômes de la même manière que ces nouveaux symptômes se produisent (et que les anciens symptômes ont cessé).

Pour référence, cela se produit lors de l'installation après avoir effacé le cache de yarn et node_modules ou mis à jour une dépendance de package git particulière.

La dépendance de package particulière est une dépendance d'un autre package git dont je dépend en fait (les deux ont des étapes prepare similaires qui reposent sur TypeScript). Si j'apporte des modifications à ces dépendances sur #master et que j'effectue un yarn upgrade --latest , le problème se produit (et sur yarn install .

Lorsque je mets à jour ce sous-paquet manuellement (dans un dossier node_modules complètement séparé!), Le yarn install fonctionne à nouveau. Cela me fait penser que yarn utilise accidentellement le cache par deux processus simultanément et cela cause les problèmes que nous voyons dans ce problème.

Cela m'arrive lorsque j'utilise 2 ou plusieurs packages installés par une dépendance git. D'une manière ou d'une autre, il existe plusieurs processus dans le même package exécutant le script prepare . En outre, il commence à échouer avec npm également dans les dernières versions.

Dependencies:
A -> B & C (both by git, with prepare script)
B -> C (by git, with prepare script)

Cela a été ouvert pendant des années et se produit toujours avec le fil 1.22.0.
J'ai juste passé des heures à essayer de déboguer ce qui se passait sans aucune chance, et il semble que je n'ai pas été le seul.

La seule solution que je vois maintenant est de passer à npm.

@gregory Dans mon cas, je me souviens qu'en juin 2019, le fil toujours plus rapide que npm.

Je recommencerais jusqu'à ce que le fil se termine en utilisant des commandes comme celle-ci:

while ! yarn install; do echo --- ; done

La solution facile pour nous était de publier un package privé et de l'utiliser à la place d'un lien git. Toujours ennuyeux cependant

while ! yarn install; do echo --- ; done

Vraiment triste que le seul correctif soit la force brute ... incroyable que personne n'ait encore résolu cela.

cc @arcanis

Essayer deux installations de fils suivantes, fonctionne la première fois, puis échoue.

Gestion des dépendances rapide, fiable et sécurisée.

Ce n'est pas fiable.
`` `[3/5] Récupération des paquets ...
erreur https://registry.yarnpkg.com/lz4/-/lz4-0.6.3.tgz: l'extraction du contenu tar d'undefined a échoué, le fichier semble corrompu: "ENOENT: aucun fichier ou répertoire de ce type, lien '/ app /.cache/yarn/v6/npm-lz4-0.6.3-78df6bb69a36d7db6c2e849494876ba6e38e66d6-integrity/node_modules/lz4/build/Release/obj.target/build/Release/lz4.arnode '->' /app/Release/lz4.arnode '->' /app/ /v6/npm-lz4-0.6.3-78
df6bb69a36d7db6c2e849494876ba6e38e66d6-intégrité / node_modules / lz4 / build / Release / obj.target / lz4.node '"
info Visitez https://yarnpkg.com/en/docs/cli/install pour obtenir de la documentation sur cette commande.
[1/5] Validation de package.json ...
[2/5] Résolution des packages ...
[3/5] Récupération des packages ...
info Il semble y avoir un problème avec votre connexion réseau. Nouvelle tentative ...
info [email protected] : La plateforme "linux" est incompatible avec ce module.
info " [email protected] " est une dépendance facultative et une vérification de compatibilité échouée. L'exclure de l'installation.
info [email protected] : La plateforme "linux" est incompatible avec ce module.
info " [email protected] " est une dépendance facultative et une vérification de compatibilité échouée. L'exclure de l'installation.
[4/5] Lier les dépendances ...
[5/5] Construction de nouveaux packages ...
$ npm run prepare: mjs && npm run prepare: js

[email protected] prepare: mjs /app/.cache/yarn/v6/.tmp/43563e016bb56318ebd76037a0f6ce2f.73d5f4dbffab6f6a27f26c6611e32662c98c2891.prepare
BABEL_ESM = 1 babel src -d. --keep-file-extension

Compilation réussie de 39 fichiers avec Babel.

[email protected] prepare: js /app/.cache/yarn/v6/.tmp/43563e016bb56318ebd76037a0f6ce2f.73d5f4dbffab6f6a27f26c6611e32662c98c2891.prepare
babel src -d.

Compilation réussie de 39 fichiers avec Babel.

[3/5] Récupération des packages ...
erreur https://registry.yarnpkg.com/lz4/-/lz4-0.6.3.tgz: l'extraction du contenu tar d'undefined a échoué, le fichier semble corrompu: "ENOENT: aucun fichier ou répertoire de ce type, lien '/ app /.cache/yarn/v6/npm-lz4-0.6.3-78df6bb69a36d7db6c2e849494876ba6e38e66d6-integrity/node_modules/lz4/build/Release/obj.target/build/Release/lz4.arnode '->' /app/Release/lz4.arnode '->' /app/ /v6/npm-lz4-0.6.3-78
df6bb69a36d7db6c2e849494876ba6e38e66d6-intégrité / node_modules / lz4 / build / Release / obj.target / lz4.node '"
info Visitez https://yarnpkg.com/en/docs/cli/install pour obtenir de la documentation sur cette commande.
info Il semble y avoir un problème avec votre connexion réseau. Nouvelle tentative ...

''

Tout le monde sait pourquoi le fil appellerait

error https://registry.yarnpkg.com/lz4/-/lz4-0.6.3.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, link '/app/.cache/yarn/v6/npm-lz4-0.6.3-78df6bb69a36d7db6c2e849494876ba6e38e66d6-integrity/node_modules/lz4/build/Release/obj.target/build/Release/lz4.node' -> '/app/.cache/yarn/v6/npm-lz4-0.6.3-
  df6bb69a36d7db6c2e849494876ba6e38e66d6-integrity/node_modules/lz4/build/Release/obj.target/lz4.node'"

quand le bon chemin aurait dû être:

/app/.cache/yarn/v6/npm-lz4-0.6.3-78df6bb69a36d7db6c2e849494876ba6e38e66d6-integrity/node_modules/lz4/build/Release/lz4.node

il semble que le fil ajoute obj.target/build/Release/ pour une raison quelconque. Pourrait être lié à https://github.com/yarnpkg/yarn/commit/0e7133ca28618513503b4e1d9063f1c18ea318e5

J'avais cette même erreur frustrante et difficile à déboguer. Le problème dans mon cas semblait être le comportement de yarn workspace causé par différentes versions de la même dépendance dans différents packages (en particulier ava versions 2 et 3). Ce n'est qu'une fois que j'ai mis à jour toutes les occurrences de ava à leur dernière que j'ai cessé de recevoir cette erreur.

J'utilise 1.22.4 et j'ai été bloqué sur ce problème pendant des heures. Notre monorepo a plusieurs modules utilisant les mêmes packages. Enfin, je l'ai trié en appliquant ce qui suit:
1) Assurez-vous que vous utilisez la même version d'un package dans tous les modules - cela provoquera un crash à coup sûr, même sur devDependencies .
2) Épinglez toutes les versions du monorepo dans tous les fichiers package.json .

Peut confirmer encore un problème sur 1.22.4 . À l'origine, c'était mocha , et après m'être assuré que tous les paquets utilisaient la même version, je reçois maintenant des erreurs générées à partir de camelcase que je n'utilise même pas dans mon projet - apparemment c'est de yargs , peut-être de Lerna.

error Une erreur inattendue s'est produite: "ENOENT: aucun fichier ou répertoire de ce type, lstat '/ code / project / src / packages / private-package / node_modules / camelcase'".

Puis-je demander s'il y a une solution en vue? Nous continuons de supprimer 20 node_modules et un yarn.lock pour y remédier.

Puis-je demander s'il y a une solution en vue? Nous continuons de supprimer 20 node_modules et un yarn.lock pour y remédier.

Personnellement, je suis passé à lerna pour la gestion de l'espace de travail.

Assez sûr que l'actuel Lerna passe simplement à Yarn.

J'ai pu contourner mes problèmes en ajoutant une configuration nohoist pour les packages Ember - mon environnement actuel utilise une ancienne version d'Ember, qui est incompatible avec les espaces de travail.

    "nohoist": [
      "**/ember-package/*ember*",
      "**/ember-package/*ember*/**",
      "**/ember-package/loader.js"
    ]

Je pense que nous avons un repro minimal ici maintenant: https://github.com/yarnpkg/yarn/issues/7212#issuecomment -637978197

Supprimer yarn.lock puis yarn install fonctionné pour moi

Des nouvelles ici? Notre processus CI vient de s'arrêter avec tous les pipelines échouant en raison de l'échec de l'installation des dépendances de fil. C'est ridicule.

La configuration de --network-concurrency ne corrige rien et les jobs s'exécutent sur des machines propres (pas de node_modules, pas de yarn .cache).

@cadavre Ne donne aucune garantie mais cela ne pose peut-être pas de problème dans la v2, vous pouvez l'essayer avec

yarn set version 2 && yarn config set nodeLinker node-modules

https://yarnpkg.com/getting-started/install#per -project-install
https://yarnpkg.com/configuration/yarnrc#nodeLinker

Cela a commencé à m'arriver aussi, après la mise à niveau de certaines de mes dépendances vue et firebase. Maintenant 100% reproductible dans mes machines CI et dev. L'ajout de --network-concurrency 1 ne résout pas le problème de manière fiable. Je ne suis pas à court d'espace disque ou d'inodes. Je suis sur WSL1. Fil 1.22.4.

Je l'ai corrigé en changeant temporairement le répertoire du cache, que je supprime juste après.

Pour moi, c'est la construction de Docker:

RUN yarn install --check-files --cache-folder .ycache && rm -rf .ycache