Cli: erreur entrée de bac non valide pour le package

J'ai une nouvelle erreur très similaire et inexpliquée dans la configuration de mon emballage. En espérant une réponse ici pour clarifier ce qui se passe.

C'était l'un des rares endroits où je pouvais même trouver un résultat raisonnable:

npm "entrée de bac non valide"

Ce qui me fait soupçonner que cela pourrait être dû à un changement récent.

Je rencontre le même problème

Je rencontre le même message d'erreur, sur NPM: v6.13.4.

Mes étapes pour reproduire sont différentes de OP, mais je suppose que c'est une cause similaire.

Nous utilisons:
npm ci && npm prune --production

Ce qui provoque
error invalid bin entry for package

En utilisant:
npm install && npm prune --production

Fonctionne bien cependant. Je suppose que npm install touche package-lock / package.json chaque fois qu'il le juge opportun et ajoute potentiellement quelque chose pour que tout cela fonctionne.

J'ai retracé ça jusqu'à
https://github.com/npm/bin-links/commit/25a34f905a0144cebcd41e56b6942117b267e005#diff -168726dbe96b3ce427e7fedce31bb0bcR85

Qui a été ajouté dans la version v6.13.3 npm.

Je ne comprends pas particulièrement ce qui se passe actuellement. J'aurai peut-être une meilleure lecture plus tard pour comprendre quelle est la cause réelle plutôt que le symptôme.

Nous ne devrions pas revenir à la v6.13.2_ car 6.13.3 et 6.13.4 le sont pour résoudre la faille de sécurité du bac;
https://blog.npmjs.org/post/189618601100/binary-planting-with-the-npm-cli

Je pense que le meilleur plan d'action pour le moment est de ne pas utiliser de pruneau jusqu'à ce que cela soit réglé, probablement après la période des vacances. :)
@samhstn @grossmannmartin @ nickv2002

@isaacs (parce que git-blame me le dit: joy

Avoir le même problème. Le voir avec différents packages:

+ npm prune
npm ERR! invalid bin entry for package [email protected]. key=portastic, value=bin/portastic

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2019-12-23T21_19_21_377Z-debug.log

Oui, on dirait que prune ne passe pas dans le dossier entièrement résolu quand il lie des bacs (ce qui, je dois dire, pourquoi _prune_ lie des bacs, cela semble quelque peu inutile, mais ok.)

Cela sera corrigé dans la prochaine version de cli. En attendant, vous pouvez peut-être utiliser npm ci --production pour accéder à l'état "deps de production installés, mais pas de développement de développement"? Ce ne sera pas bien si vous dépendez de regrouper vos deps dans le repo git, bien sûr, car ci jette le node_modules existant s'il en trouve un, mais essayant simplement de penser des solutions de contournement que vous pourriez utiliser.

Des nouvelles sur la date de mise en ligne de ce correctif?

6.13.5 sortira mardi de la semaine prochaine, le 07/01/2019, avec une mise à jour de pacote et bin-links pour résoudre ce problème et un autre.

Même chose ici. Savez-vous approximativement à quelle heure il sera mis à jour aujourd'hui?

Ce problème m'a rendu fou ces derniers jours, y a-t-il une idée de la date à laquelle le correctif sera disponible? il a cassé tous mes déploiements automatiques via TeamCity, nous sommes donc bloqués pour pouvoir déployer et QA nos produits.

Désolé pour le retard. J'ai débogué un échec étrange sur GH Actions Windows CI. Nous prévoyons de sortir cela dans les prochains jours, au plus longtemps.

@jwwtaker, vous pouvez simplement utiliser les commandes dans l'ordre inverse jusqu'à la sortie du correctif:

• npm installer
• npm pruneau

npm prune ne fonctionne toujours pas pour moi en utilisant npm v6.13.6 .

De la description originale:

À partir du clonage de ce référentiel: https://github.com/samhstn/invalid-bin-entry , puis en cours d'exécution:

cd assets
npm prune

produit l'erreur suivante:

npm ERR! invalid bin entry for package [email protected]. key=jsesc, value=bin/jsesc

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/samhstn/.npm/_logs/2020-01-13T13_17_57_425Z-debug.log

Et le journal de débogage suivant: 2020-01-13T13_17_57_425Z-debug.log

Nous avons le même problème mais ne pouvons pas utiliser ces solutions de contournement car les commandes sont exécutées par le buildpack Heroku. Nous sommes bloqués à npm 6.13.2 (le problème se produit depuis npm 6.13.3), ou nous devons supprimer package-lock.json (le problème se produit uniquement avec ce fichier). npm 6.13.5 ne le résout pas, ni npm 6.13.6.

une mise à jour sur ce @isaacs ?

Mon Azure DevOps CI me donnait la même erreur, donc, juste au cas où quelqu'un aurait besoin d'aide pour résoudre temporairement ce problème:

• Ajoutez une nouvelle tâche dans votre pipeline avant votre installation npm prune ou npm appelée "Node.js tool installer"
• Définissez 13.3.0 comme dans le champ "Version Spec" et réexécutez.

Cela a fonctionné pour moi.

Contrairement à certaines personnes ci-dessus, la mise à jour de npm 6.13.4 à 6.13.6 résolu le problème dans mon cas, donc au moins nous savons que _ certains_ problèmes ont été résolus. J'espère que cela pourra être corrigé pour tout le monde aussi.

Après 20 jours, au moins une mise à jour des progrès serait formidable.