NPM échoue en raison de la création (?) de verrous (et non de package-lock.json) lors de l'installation.
lchown
npm (pas package-lokc.json).where
.npm install
npm test node
Se produit également localement sur Linux avec les mêmes étapes de reproduction, par exemple
npm ERR! syscall lchown
npm ERR! path /home/nathansa/.npm/_locks/staging-33722a1ecded5100.lock
npm ERR! errno -2
npm ERR! enoent ENOENT: no such file or directory, lchown '/home/nathansa/.npm/_locks/staging-33722a1ecded5100.lock'
npm ERR! enoent This is related to npm not being able to find a file.
Semble se produire moins lorsque je passe au nœud 11.0.0 + npm 6.7.0.
Le nœud 11.0.0 est une version vraiment étrange car le nœud 11 est en fin de vie depuis un certain temps. Essayez peut-être le LTS 12.13.1 actuel ? Ou c'est peut-être l'ancienne version de NPM fournie avec le nœud 11 qui évite cela.
Ouais, je voyageais juste en arrière à travers les versions que j'ai installées jusqu'à ce que je trouve une version non problématique. L'ancienne version de npm est très probablement la variable.
@sandersn peut-être effectuer une recherche binaire manuelle dans les versions ? 😛
Rencontrer ce bogue lors de l'utilisation cohérente de Lerna, ce qui cause malheureusement des problèmes dans notre processus de construction.
Message d'erreur:
lerna ERR! npm install stderr:
| npm ERR! code ENOENT
| npm ERR! syscall lchown
| npm ERR! path /root/.npm/_locks/staging-3f138bd09ee0de58.lock
| npm ERR! errno -2
| npm ERR! enoent ENOENT: no such file or directory, lchown '/root/.npm/_locks/staging-3f138bd09ee0de58.lock'
| npm ERR! enoent This is related to npm not being able to find a file.
| npm ERR! enoent
C'est lors de l'utilisation de l'image docker node:latest-alpine
, qui utilise actuellement les versions :
nœud : 12.13.1
npm : 6.12.1
Je peux confirmer que cela m'arrive également avec le nœud v13.2.0 et npm 6.13.4.
Quelqu'un a une solution temporaire pour cela? Comme cela bloque certains de nos déploiements. :(
@midudev temp mitigation consiste à ne pas exécuter npm i
en parallèle ou au moins à réduire considérablement la simultanéité.
Lorsque vous traitez avec le repo DT en le limitant à 2 installations parallèles, cela réduit le nombre d'échecs d'environ 90 %.
Merci @SimonSchick. Oui... L'absence de simultanéité semble résoudre le problème, mais le temps nécessaire à l'installation des packages est considérablement augmenté. :(
Je me demande si l'équipe npm est au courant de ce problème car cela fonctionnait bien auparavant. De s'il s'agit d'un problème causé par certains changements internes sur le nœud.
Bonjour, nous avons le même problème.
Je suis presque sûr qu'il s'agit d'une sorte de problème de condition de course.
La solution temporaire consiste à rétrograder à [email protected]
.
J'ai testé presque toutes les versions de 6.10.2
à la dernière 6.13.6
et le problème est là.
Je peux confirmer que le bogue n'est PAS lié à la version nodejs
, il est juste lié à la version npm
.
Nous rencontrons le même problème pour npm i
contre https://github.com/strongloop/loopback-next , qui est un lerna monorepo. npm i
au niveau racine déclenche l'installation de npm pour plusieurs packages en parallèle. La réduction de la simultanéité réduit également les chances d'exécuter le problème signalé.
Nous pouvons obtenir plus d'informations sur le fichier de verrouillage avec NODE_DEBUG=lockfile npm i
.
Après quelques débogages, j'ai trouvé le problème autour de https://github.com/npm/cli/blob/latest/lib/utils/correct-mkdir.js#L31. Si npm
est exécuté simultanément, plusieurs processus appellent chownr
contre ~/.npm/_locks
. L'implémentation de chownr
lit tous les fichiers du répertoire et essaie d'appliquer chown
à chacun des fichiers. Certains fichiers peuvent être supprimés entre readdir
et lchown
et cela conduit à ENOENT
.
@isaacs Veuillez me faire savoir si https://github.com/raymondfeng/chownr/commit/e4c7b59fe4142995ae36c71de3435d2e2a7e4319 est le bon endroit pour résoudre ce problème. Si c'est le cas, j'essaierai d'ajouter quelques tests et de soumettre un PR.
@raymondfeng Cela ressemble à un changement raisonnable. Oui, veuillez envoyer un PR à chownr.
@isaacs PR soumis - https://github.com/npm/cli/issues/496. Merci pour votre réponse rapide.
Commentaire le plus utile
Après quelques débogages, j'ai trouvé le problème autour de https://github.com/npm/cli/blob/latest/lib/utils/correct-mkdir.js#L31. Si
npm
est exécuté simultanément, plusieurs processus appellentchownr
contre~/.npm/_locks
. L'implémentation dechownr
lit tous les fichiers du répertoire et essaie d'appliquerchown
à chacun des fichiers. Certains fichiers peuvent être supprimés entrereaddir
etlchown
et cela conduit àENOENT
.