Deliver us from dependency hell

Deliver us from dependency hell

La mayoría de los servicios y aplicaciones modernos tienen una gran cantidad de dependencias que viven en una carpeta node-modules en constante crecimiento. En general, muchas de estas bibliotecas se mantienen, cambian y actualizan activamente. Si sus dependencias están mal administradas, puede encontrarse rápidamente en un infierno de dependencias.

Si no está familiarizado con npm, compruébelo aquí antes de leer en

Shopping Compras de comestibles

Al iniciar una aplicación de nodo, uno de los primeros pasos es ejecutar npm install. Cuando ejecute esto, node buscará un archivo llamado package.json en la base de su proyecto. Si se encuentra ese archivo, usará la sección dependency como una especie de» lista de compras de comestibles «para ir y recopilar» ingredientes » (bits de código) que requiere su aplicación.
 Texto alternativo
La «tienda de comestibles» en este caso es algo que npm llama a registry. De forma predeterminada, la aplicación node buscará estos paquetes en el registro público de npm, donde estará casi todo lo que necesita (se pueden crear registros privados para código propietario y demás). Si el paquete se encuentra en el registro, node coloca ese «ingrediente» en un directorio node_modules en la base del proyecto.

Es importante tener en cuenta que los paquetes que necesite pueden tener su propia «lista de compras» (paquete.json), y todas esas dependencias anidadas deben resolverse antes de que la aplicación pase a la siguiente dependencia de su propio paquete.json.

Texto Alternativo

⬆️ Versiones, Care Comillas y Wild Comodines

Las versiones de sus dependencias son generalmente algo como v1.3.5. Esto se denomina versionado semántico o semver. Con semver, los números representan cambios en el código de severidad variable – MAJOR.MINOR.PATCH.
De sus documentos –

Versión PRINCIPAL cuando realiza cambios incompatibles en la API,
Versión menor cuando agrega funcionalidad de manera compatible con versiones anteriores y
Versión DE parche cuando corrige errores compatibles con versiones anteriores.

Con esto en mente, muchas personas quieren actualizar automáticamente su aplicación con cualquier cosa nueva que sus dependencias puedan tener en cambios nuevos y sin interrupciones.

El prefijo con tilde ~ le dará cualquier nueva actualización PATCH, pero no mayor ni menor. Por lo tanto, ~1.3.1 podría instalar 1.3.9, pero no 1.4.0

El prefijo con caret ^ le dará cualquier nueva versión PATCH y MINOR, pero no mayor. Por lo tanto, ^1.3.1 podría instalar 1.4.9 pero no 1.5.0
 Texto alternativo
 Texto alternativo

Echemos un vistazo al árbol de dependencias de nuestro código de ejemplo:

my-breakfast | | milk | |coffee-script 

Vale, más como un palo, pero espero que la cadena de dependencia esté clara. Nuestro paquete.json requiere la versión v0.5.0 específicamente de milk, pero milk requiere coffee-script en cualquier lugar de 0.9.6 a 1.0.0. npm install se ejecuta, desarrollamos nuestra aplicación, todo está perfecto.

Now Ahora avancemos 2 meses. Alguien encuentra tu proyecto y quiere contribuir. Bifurcan y clonan tu repositorio, ejecutan npm install, aaaa y no funciona. «Pero funcionó en mi máquina!»lloras. Cuando su colaborador instaló los módulos de nodo, se les garantizó una versión específica de milk, pero obtuvieron una versión diferente de coffee-script porque el paquete de milk.json usó semver.

Setting Configurar sus dependencias en stone

Una solución para esto es usar un archivo package-lock.json. Este archivo le da un control muy granular sobre las versiones de cada dependencia que instale. Si su package.json es como la lista de compras, entonces su package-lock.json es como un presupuesto. Puedes comer cereal, pero será de marca de tienda en lugar de Cap’n Crunch. Esta especificidad se extiende por todas las ramas del árbol de dependencias. Debes tener un package.json si quieres usar un archivo de bloqueo (el package.json hace mucho más que solo administrar dependencias, ese es el enfoque de esta publicación).

Wrapping Terminando

Personalmente siento que un archivo package-lock.json siempre debe usarse (en las versiones más recientes de npm, en realidad se genera automáticamente). Simplemente hace que todo sea más confiable en entornos e implementaciones. Aquí hay algunas últimas pepitas para ayudar cuando se trata de dependencias:

  • npm install --save actualizará automáticamente su archivo de bloqueo y paquete.json con ese paquete.
  • npm ci en lugar de solo npm install reconstruirá automáticamente los módulos de nodo y los compilará a partir de su archivo de bloqueo. Es un comando realmente útil para CI / CD y generalmente es mejor usarlo en conjunto con un archivo de bloqueo.
  • Para proyectos más grandes y una dependencia súper robusta, consulte docker y contenedores. Puede funcionar casi como una máquina virtual que contiene perfectamente su código y sus dependencias, y se clona para promoverlo a diferentes entornos. Así que espero que termines con muchos menos problemas de «funcionó en mi máquina».

Deja una respuesta

Tu dirección de correo electrónico no será publicada.