Nous avons découvert cela lorsque l'un des packages internes de notre société a refactoré et déplacé le point d'entrée ailleurs dans le référentiel sans se souvenir de mettre à jour le main
dans package.json. Le résultat final était que npm pack
créé avec bonheur et permettait de publier un paquet qui n'avait aucune chance de fonctionner correctement.
Quand npm pack
et donc quand npm publish
sont exécutés
npm pack
ne valide pas que le main
existe dans l'archive tar, ce qui facilite la création et la publication de paquets qui ne peuvent pas être utilisés par les consommateurs.
npm init
et pas à pas en créant tout avec les valeurs par défaut. Vous obtiendrez un package.json
comme celui-ci{
"name": "npm-repro",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"author": "",
"license": "ISC"
}
npm pack
dans ce répertoire et observez que l'archive tar est créée avec plaisirnpm notice
npm notice 📦 [email protected]
npm notice === Tarball Contents ===
npm notice 205B package.json
npm notice === Tarball Details ===
npm notice name: npm-repro
npm notice version: 1.0.0
npm notice filename: npm-repro-1.0.0.tgz
npm notice package size: 241 B
npm notice unpacked size: 205 B
npm notice shasum: ca39bc17447e27ef2fd0dea656e0e6b473f310d7
npm notice integrity: sha512-p8tZD8W438r7t[...]7Oo0YMcAoNPzQ==
npm notice total files: 1
npm notice
npm-repro-1.0.0.tgz
Il n'y a pas de index.js
, donc si ce paquet tentait d'être utilisé, il ne fonctionnerait pas.
npm pack
quitterait avec un code de sortie différent de zéro, ce qui entraînerait également l'échec de npm publish
et empêcherait les paquets dont les archives tar ne contiennent pas le main
du package.json
d'être publié dans un registre.Notre société a rencontré ce problème en essayant de publier dans notre registre interne.
Je ne sais pas si cela convient mieux comme bogue pour npm-packlist
. Je ne sais pas vraiment comment l'organisation npm
veut maintenir la séparation des préoccupations entre les deux. C'est-à-dire que npm-packlist
simplement renvoyer aveuglément une liste de fichiers qui devraient tenter d'être inclus sans faire aucune validation et laisser cette validation d'ordre supérieur pour avoir lieu dans tous les paquets qui veulent consommer la fonctionnalité de npm-packlist
?
Ce n'est pas le travail de npm-packlist, c'est le travail de npm publish
si quelque chose.
Cela semble raisonnable. Pour une raison quelconque, mon entreprise a utilisé npm pack
to comme test pour voir si la publication se terminera avec succès. npm publish --dry-run
est probablement un meilleur chèque.
Commentaire le plus utile
Cela semble raisonnable. Pour une raison quelconque, mon entreprise a utilisé
npm pack
to comme test pour voir si la publication se terminera avec succès.npm publish --dry-run
est probablement un meilleur chèque.