Ventajas de las dependencias empaquetadas sobre las dependencias normales en NPM

npm nos permite especificar dependencias agrupadas, pero ¿cuáles son las ventajas de hacerlo? Supongo que si queremos estar absolutamente seguros de que obtenemos la versión correcta, incluso si se elimina el módulo al que hacemos referencia, o ¿quizás haya un beneficio de velocidad con la agrupación?

¿Alguien sabe las ventajas de las dependencias agrupadas sobre las dependencias normales?

Extracto de la definición de Dependencias empaquetadas aquí para su conveniencia:

BundledDependencias
Conjunto de nombres de paquetes que se incluirán al publicar el paquete.

Si esto se deletrea “dependencias de paquete”, entonces eso también es honorable.

Por ejemplo, bundledDependencies: ['foo', 'bar']

Uno de los mayores problemas ahora con Node es lo rápido que está cambiando. Esto significa que los sistemas de producción pueden ser muy frágiles y una npm update puede romper cosas fácilmente.

El uso de BundledDependencies es una forma de solucionar este problema asegurando, como usted conjetura correctamente, que siempre entregará las dependencias correctas sin importar lo que pueda estar cambiando.

También puede usar esto para agrupar sus propios paquetes privados y entregarlos con la instalación.

Para el lector rápido : este QA es sobre el campo package.json bundledDependencies, no sobre el paquete .

Lo que hacen las dependencias agrupadas

“Dependencias dependientes” es exactamente lo que su nombre implica. Dependencias que deben estar dentro de su proyecto. Así que la funcionalidad es básicamente la misma que las dependencias normales. También se empaquetarán cuando se ejecute el npm pack .

Cuando usarlos

Las dependencias normales normalmente se instalan desde el registro npm. Por lo tanto, las dependencias agrupadas son útiles cuando:

  • desea reutilizar una biblioteca de terceros que no proviene del registro de npm o que se modificó
  • Quieres reutilizar tus propios proyectos como módulos.
  • Quieres distribuir algunos archivos con tu módulo.

De esta manera, no tiene que crear (y mantener) su propio repository de npm, sino obtener los mismos beneficios que obtiene de los paquetes de npm.

Cuándo no usar dependencias agrupadas

Al desarrollar, no creo que el punto principal sea prevenir actualizaciones accidentales. Tenemos mejores herramientas para eso, a saber, repositorys de código (git, mercurial, svn …) o ahora archivos de locking.

Para fijar 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 archivo package-lock.json (consulte el blog de nodos y la versión del nodo 8)

  • Opción 2: utilizar hilo en lugar de npm . Es un gestor de paquetes de facebook, más rápido que npm y utiliza un archivo yarn.lock . Utiliza el mismo package.json contrario.

Esto es comparable a los archivos de locking en otros gestores de paquetes como Bundler o Cargo. Es similar a npm-shrinkwrap.json de npm, sin embargo, no tiene pérdidas y crea resultados reproducibles.

npm realidad copió esa característica del yarn , entre otras cosas.

  • Opción 3: este fue el enfoque recomendado anteriormente, que ya no recomiendo. La idea era utilizar npm shrinkwrap mayor parte del tiempo y, a veces, colocar todo el contenido, incluida la carpeta node_module, en el repository de código. O posiblemente use shrinkpack . Las mejores prácticas en ese momento se discutieron en el blog node.js y en los sitios web de desarrolladores de Joyent .

Ver también

Esto está un poco fuera del scope de la pregunta, pero me gustaría mencionar el último tipo de dependencias (que yo sepa): las dependencias entre pares . También vea esta pregunta de SO relacionada y posiblemente la documentación del yarn en las Dependencias empaquetadas .

Otra ventaja es que puede poner sus dependencias internas (componentes de la aplicación) allí y simplemente solicitarlas en su aplicación como si fueran módulos independientes en lugar de saturar su lib / y publicarlas en npm.

Si / cuando maduran hasta el punto en que puedan vivir como módulos separados, puede colocarlos en npm fácilmente, sin modificar su código.

Me sorprende que no haya visto esto aquí ya, pero cuando se seleccionan cuidadosamente, las bundledDependencies se pueden usar para producir un paquete distribuible desde un paquete npm pack que se ejecutará en un sistema donde npm no está configurado. Esto es útil si, por ejemplo, tiene un sistema que no está en red / no está en Internet: traiga su paquete en una unidad de npm run USB (o lo que sea) y desempaquete el npm run , luego npm run o node index.js y simplemente funciona.

Tal vez haya una mejor manera de empaquetar su aplicación para ejecutar “sin conexión”, pero si la hay, no la he encontrado.

Operativamente, veo las Dependencias agrupadas como la tienda de módulos privada de un módulo, donde las dependencias son más públicas, resueltas entre su módulo y sus dependencias (y dependencias secundarias). Su módulo puede depender de una versión anterior de, digamos, reactjsr, pero una dependencia requiere lo último y lo mejor. Su paquete / instalación resultará en su versión node_modules/$yourmodule/node_modules/react en node_modules/$yourmodule/node_modules/react , mientras que su dependencia obtendrá su versión en node_modules/react (o node_modules/$dependency/node_modules/react si están tan inclinados).

Una advertencia: recientemente me topé con una dependencia que no configuró correctamente su dependencia en la reacción, y al haber reactjsdo en las Dependencias agrupadas, el módulo dependiente falló en el tiempo de ejecución.