En mi opinión, la mejor práctica es publicar tanto el código minimizado en la carpeta dist como el código fuente en la carpeta src . También se deben incluir otros archivos como package.json , package-lock.json , README.md , LICENSE.txt , CONTRIBUTING.md , etc., que se encuentran en el directorio raíz del paquete.

Para lograr esto, se debe usar la propiedad de files en package.json para incluir en la lista blanca lo que debe publicarse en npm en lugar de encontrar lo que no se requiere publicar mediante la lista negra en .npmignore .

La carpeta dist solo debe tener un paquete minimizado y no es necesario generar otro package.json en la carpeta dist eliminando scripts, devDependencies , etc.

Esto se debe a que cuando el consumidor del paquete hace npm install <package name> , solo instala los paquetes dentro dependencies e ignora los paquetes bajo devDependecies .

Los archivos minimizados pueden ser utilizados por el navegador refiriéndose directamente desde la etiqueta de scripts donde el tiempo de carga será menor debido al tamaño de archivo pequeño, mientras que los marcos modernos como angular usarán código no minimizado. Los marcos modernos tienen sus propias herramientas de compilación, como webpack / rollup , que crean un archivo de paquete minimizado.

No es necesario tener un package.json de nivel superior que tenga un punto de entrada en el campo main al archivo relevante en dist . En cambio, en mi opinión, el package.json de nivel superior.json debería tener un punto de entrada a un archivo relevante como index.js en el mismo nivel de paquete raíz.

Finalmente, uno puede ejecutar npm pack para ver qué hay dentro del tarball y luego, finalmente, npm publish npm en el registro npm para uso público desde la carpeta del paquete raíz.

La práctica común es tener un código fuente en npm, no el resultado de transpilación/minificación/etc. También es común publicar módulos que no necesitan ninguna transpilación en primer lugar.

Si su módulo no se puede usar en Node directamente sin transpilación (lo que sería muy inusual para un módulo en npm y ciertamente no se espera), entonces debe asegurarse de que se transpile durante la instalación (lo cual es complicado y puede dañar el sistema de archivos del usuario si se hace mal) o para incluir el dist en sus módulos publicados.

Si va a incluir el dist en el módulo publicado, debe asegurarse de que se cargue el archivo correcto cuando las personas requieran su módulo y que siempre cree un dist nuevo antes de hacer npm version npm publish .

Sin embargo, mi consejo sería escribir sus módulos de Node en Node. De esa manera, se podrán usar directamente con una pequeña descarga, una instalación rápida, sin problemas con la transpilación y mensajes de error legibles; la última parte es muy importante durante la depuración.

Hay un problema grave con la publicación de código transpilado que a menudo se pasa por alto. La publicación de código que sea diferente de alguna forma del código fuente real, ya sea transpilado, minimizado u ofuscado de alguna manera, tiene algunas implicaciones de seguridad. Es muy difícil auditar los resultados de la transpilación y debe hacerlo si ese es el código que realmente se está ejecutando (especialmente si no lo transpiló usted mismo).