Ventajas de bundledDependencies sobre dependencias normales en NPM

Question

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

¿Alguien conoce las ventajas de bundledDependencies sobre las dependencias normales?

Extracto de bundledDependencies definición aquí por conveniencia:

bundledDependencies
matriz de nombres de paquetes que se incluirá al publicar el paquete.

Si esto se deletrea "bundleDependencies", entonces eso también es honorable.

E.g. bundledDependencies: ['foo', 'bar']

Answer 1

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 un npm update puede romper cosas fácilmente.

Usar bundledDependencies es una forma de evitar este problema al garantizar, como correctamente conjetura, 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.

Answer 2

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 ocupar su lib/y publicarlas en npm.

Si se han madurado hasta el punto en que podrían vivir como módulos separados, puede ponerlos en npm fácilmente, sin modificar su código.

Answer 3

Para el lector rápida: este control de calidad es sobre el campo package.json bundledDependencies, no sobre la package.

Qué hacer bundledDependencies

"bundledDependencies" son exactamente lo que su nombre implica. Dependencias que deberían estar dentro de tu proyecto. Entonces la funcionalidad es básicamente la misma que las dependencias normales. También se empaquetarán al ejecutar npm pack.

Cuando se les utilice

dependencias normales suelen instalarse desde el registro NPM. dependencias Así paquetes son útiles cuando:

• desea volver a utilizar una biblioteca de terceros que no proviene del registro de la NGP, o que se modificó
• desea volver a utilizar sus propios proyectos como módulos
• quiere distribuir algunos archivos con el módulo

de esta manera, usted no tiene que crear (y mantener) su propio repositorio de la NGP, pero obtener los mismos beneficios que se obtienen de los paquetes de la NGP.

Cuando no de utilizar las dependencias

Al desarrollar liado, no creo que el punto principal es prevenir cambios accidentales sin embargo. Tenemos mejores herramientas para eso, a saber, repositorios de código (git, mercurial, svn ...) o ahora bloquear archivos.

Para anclar sus versiones de paquetes, puede utilizar:

• Opción 1: Utilice la versión más nueva NGP 5 que viene con el nodo 8. Utiliza un archivo package-lock.json (ver el node blog y la liberación de nodo 8)

• Opción2: use yarn en lugar de npm. Es un administrador de paquetes de Facebook, más rápido que npm y usa un archivo yarn.lock. Utiliza el mismo package.json de lo contrario.

Esto es comparable a ficheros de bloqueo en otros gestores de paquetes como Bundler o carga. Es similar al npm-shrinkwrap.json de npm, sin embargo, no es con pérdida y genera resultados reproducibles.

npm realidad copiaron esa característica de yarn, entre otras cosas.

• Opción 3: este fue el enfoque recomendado anteriormente, que ya no recomiendo. La idea era usar npm shrinkwrap la mayor parte del tiempo, y algunas veces poner todo, incluida la carpeta node_module, en el depósito de código. O posiblemente use shrinkpack. Las mejores prácticas en ese momento se discutieron en el sitio web node.js blog y en los sitios web joyent developer.

Ver también

Esto es un poco fuera del alcance de la cuestión, pero me gustaría hablar de la última clase de dependencias (que yo sepa): peer dependencies. También vea esto related SO question y posiblemente el los documentos de yarn en bundledDependencies.

Answer 4

Operativamente, miro 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, reaccionar, pero una dependencia requiere lo último y lo mejor.Su paquete/instalación dará como resultado su versión anclada 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 así lo desean).

Una advertencia: Recientemente me encontré con una dependencia que no configuró adecuadamente su dependencia en reaccionar, y al reaccionar en bundledDependencies provocó que ese módulo dependiente fallara en el tiempo de ejecución.