npm nos permite especificar bundledDependencies, pero ¿cuáles son las ventajas de hacerlo? Supongo que si queremos estar absolutamente seguros de obtener la versión correcta incluso si se elimina el módulo al que hacemos referencia, ¿o quizás hay un beneficio de velocidad con la agrupación?
¿Alguien conoce las ventajas de bundledDependencieslas dependencias normales?
Respuestas:
Uno de los mayores problemas en este momento con Node es qué tan rápido está cambiando. Esto significa que los sistemas de producción pueden ser muy frágiles y npm updatepueden romper cosas fácilmente.
El uso de bundledDependencies es una forma de solucionar este problema asegurándose, como supone correctamente, de que siempre entregará las dependencias correctas sin importar qué más pueda estar cambiando.
También puede usar esto para agrupar sus propios paquetes privados y entregarlos con la instalación.
npm updateque no afectará a ninguna dependencia en bundledDependencies?
Para el lector rápido : este control de calidad se trata delcampo package.json bundledDependencies, no del paquete .
"bundledDependencies" es exactamente lo que implica su nombre. Dependencias que deberían estar dentro de tu proyecto. Entonces, la funcionalidad es básicamente la misma que las dependencias normales. También estarán empaquetados cuando estén en funcionamiento npm pack.
Las dependencias normales generalmente se instalan desde el registro npm. Por tanto, las dependencias agrupadas son útiles cuando:
De esta manera, no tiene que crear (y mantener) su propio repositorio npm, sino obtener los mismos beneficios que obtiene de los paquetes npm.
Sin embargo, al desarrollar, no creo que el punto principal sea evitar actualizaciones accidentales. Tenemos mejores herramientas para eso, a saber, repositorios de código (git, mercurial, svn ...) o ahora bloquear archivos.
Para anclar las versiones de su paquete, puede usar:
Opción 1: utilice la versión 5 de NPM más reciente que viene con el nodo 8. Utiliza un package-lock.jsonarchivo (consulte el blog del nodo y la versión del nodo 8)
Option2: use hilo en lugar de npm. Es un administrador de paquetes de facebook, más rápido que npmy usa un yarn.lockarchivo. De lo package.jsoncontrario, usa lo mismo .
Esto es comparable a los archivos de bloqueo en otros administradores de paquetes como Bundler o Cargo. Es similar a npm-shrinkwrap.json de npm, sin embargo, no tiene pérdidas y crea resultados reproducibles.
npmen realidad copió esa característica yarn, entre otras cosas.
npm shrinkwrapmayor parte del tiempo y, a veces, poner todo, incluida la carpeta node_module, en su repositorio de código. O posiblemente use un paquete retráctil . Las mejores prácticas en ese momento se discutieron en el blog node.js y en los sitios web de desarrolladores joyent .Esto está un poco fuera del alcance de la pregunta, pero me gustaría mencionar el último tipo de dependencias (que yo sepa): dependencias entre pares . Consulte también esta pregunta de SO relacionada y posiblemente los documentos yarnsobre bundledDependencies .
npm install -g shrinkpackherramienta.
Otra ventaja es que puede poner sus dependencias internas (componentes de la aplicación) allí y luego simplemente requerirlas en su aplicación como si fueran módulos independientes en lugar de saturar su lib / y publicarlos en npm.
Si / cuando están maduros hasta el punto de que podrían vivir como módulos separados, puede ponerlos en npm fácilmente, sin modificar su código.
Me sorprende no haber visto esto aquí ya, pero cuando se selecciona cuidadosamente, bundledDependenciesse puede usar para producir un paquete distribuible npm packque se ejecutará en un sistema donde npmno está configurado. Esto es útil si, por ejemplo, tiene un sistema que no está en red / no está en Internet: lleve su paquete a una memoria USB (o lo que sea) y descomprima el tarball, entonces npm runo node index.jsy simplemente funciona.
Tal vez haya una mejor manera de agrupar su aplicación para que se ejecute "sin conexión", pero si la hay, no la he encontrado.
Operacionalmente, veo bundledDependencies como la tienda de módulos privados de un módulo, donde las dependencias son más públicas, resueltas entre su módulo y sus dependencias (y subdependencias). Su módulo puede depender de una versión anterior de, digamos, react, pero una dependencia requiere lo último y lo mejor. Su paquete / instalación dará como resultado su versión anclada node_modules/$yourmodule/node_modules/react, mientras que su dependencia obtendrá su versión node_modules/react(o node_modules/$dependency/node_modules/reactsi así lo desean).
Una advertencia: recientemente me encontré con una dependencia que no configuraba correctamente su dependencia en reaccionar, y haber reaccionado en bundledDependencies hizo que ese módulo dependiente fallara en tiempo de ejecución.