Descubrimos esto cuando uno de los paquetes internos de nuestra empresa hizo una refactorización y movió el punto de entrada a otra parte del repositorio sin recordar actualizar el main
en el package.json. El resultado final fue que npm pack
creó felizmente y permitió que se publicara un paquete que no tenía ninguna posibilidad de funcionar correctamente.
Cuando npm pack
y por lo tanto cuando npm publish
se ejecutan
npm pack
no valida que el main
exista en el tarball, lo que hace que sea algo fácil de crear y publicar paquetes que los consumidores no pueden usar.
npm init
y paso a paso la creación de todo con los valores predeterminados. Obtendrás package.json
como este{
"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
en este directorio y observe que el tarball se crea felizmentenpm 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
No hay index.js
, por lo que si este paquete alguna vez intentara usarse, no funcionaría.
npm pack
saldría con un código de salida distinto de cero, lo que también haría que npm publish
fallara y evitaría paquetes cuyos tarballs no contienen el main
del package.json
se publique en un registro.Nuestra empresa se encontró con esto al intentar publicar en nuestro registro interno.
No estoy seguro de si esto es más adecuado como error para npm-packlist
. No estoy completamente seguro de cómo la organización npm
quiere mantener la separación de preocupaciones entre los dos. Es decir, debería npm-packlist
devolver ciegamente una lista de archivos que deberían intentar incluirse sin realizar ninguna validación y dejar que la validación de orden superior tenga lugar en cualquier paquete que desee consumir la funcionalidad de npm-packlist
?
Este no es el trabajo de npm-packlist, es el trabajo de npm publish
todo caso.
Eso suena razonable. Por el motivo que sea, mi empresa ha decidido utilizar npm pack
to como prueba para ver si las publicaciones se completarán correctamente o no. npm publish --dry-run
probablemente sea un mejor cheque.
Comentario más útil
Eso suena razonable. Por el motivo que sea, mi empresa ha decidido utilizar
npm pack
to como prueba para ver si las publicaciones se completarán correctamente o no.npm publish --dry-run
probablemente sea un mejor cheque.