Administración de actualizaciones de dependencias en el proyecto de Node.js
Como desarrollador en Tailwind Traders, es importante mantener nuestros paquetes actualizados. Esto ayuda a garantizar nuestro uso de las características y correcciones más recientes. También nos ayuda a evitar vulnerabilidades de seguridad. En esta unidad, aprenderá a administrar dependencias en un proyecto de Node.js. Aprenderá a actualizar paquetes, usar el control de versiones semántico y administrar incidencias de seguridad.
Consideraciones antes de actualizar un paquete
Antes de actualizar un paquete, tenga en cuenta lo siguiente:
- Tipo de actualización: Comprenda si se trata de una corrección secundaria, una nueva característica o un cambio importante que podría interrumpir el código. El control de versiones semántico puede ayudar a identificar esto.
- Configuración del proyecto: Asegúrese de que el proyecto esté establecido para recibir solo actualizaciones deseadas con el fin de evitar cambios inesperados.
- Seguridad: Manténgase al tanto de las posibles vulnerabilidades. Use la característica de auditoría de npm para identificar y actualizar paquetes problemáticos.
- Pruebas: Asegúrese de pasar las pruebas después de la actualización. Si no tiene pruebas, considere la posibilidad de agregarlas. La aplicación puede comportarse de forma diferente después de una actualización y las pruebas validan el comportamiento correcto.
Control de versiones semántico para definir el comportamiento de actualización
El control de versiones semántico es un estándar clave en el desarrollo de software. Es fundamental tanto para la publicación como para el uso de paquetes de npm Ayuda a administrar los riesgos de actualización indicando el tipo de cambios en una nueva versión. Un número de versión tiene secciones específicas para reflejar estos cambios:
Tipo de versión | Posición | Sintaxis | Qué sucede | Enfoque de actualización |
---|---|---|---|---|
Major | 1º | x.0.0 o * | Los cambios de 1.0.0 a 2.0.0 indican cambios importantes. Pueden ser necesarios ajustes de código. | Comodidad con actualizaciones inmediatas a la versión principal más reciente y reconocimiento de posibles cambios de código. |
Minor | 2º | 1.x.1 o ^ | Los cambios de 1.2.9 a 1.3.0 presentan nuevas características. El código existente debería seguir funcionando. Normalmente, las actualizaciones son seguras. | Aceptación de nuevas características, pero sin cambios importantes. |
Revisión | 3rd (tercero) | 1.1.x o ~ | Los cambios de 1.0.7 a 1.0.8 significan correcciones de errores. Las actualizaciones deberían ser seguras. | Aceptación de correcciones de errores. |
En el caso de los proyectos de Node.js pequeños, puede actualizar libremente a las versiones más recientes. En el caso de los proyectos más grandes, sin embargo, las actualizaciones requieren una minuciosa reflexión y no siempre son automáticas. Por lo general, la actualización de dependencias más pequeñas, con menos dependencias propias, facilita el proceso.
Antes de actualizar una o más dependencias, debe configurar el archivo package.json
para obtener un comportamiento predecible al ejecutar el comando npm update <name of dependency>
. Node.js usa un conjunto de símbolos que le permiten definir cómo quiere que se actualicen los paquetes.
Actualización de un paquete con la CLI de npm
Puede instalar un paquete mediante el comando install
o update
en npm. Ahora estos comandos son principalmente intercambiables. Para actualizar un paquete, normalmente se usa:
- Versión más reciente:
npm update <package name>@latest
. - Versión específica:
npm update <package name>@<optional version number>
.
El proceso de actualización depende de dos factores:
- Argumento de versión: Si se especifica un número de versión en el comando
npm update
, npm captura e instala esa versión específica. - Entrada del archivo de manifiesto: El archivo
package.json
contiene reglas para actualizar las dependencias. Por ejemplo,"dependencyName": "1.1.x"
significa que npm capturará la versión que coincida con este patrón.
Descripción del control de versiones
Tres archivos controlan el control de versiones de las dependencias:
package.json
: Este archivo define la versión del paquete que desea usar. Es el archivo de manifiesto del proyecto. Contiene los metadatos del proyecto, incluidas las dependencias.package-lock.json
: Este archivo describe el árbol exacto que se generó, de modo que las instalaciones posteriores pueden generar árboles idénticos, independientemente de las actualizaciones de dependencias intermedias. Este archivo está pensado para enviarse a repositorios de origen.shrinkwrap.json
: El comando de la CLInpm shrinkwrap
crea este archivo y es similar apackage-lock.json
. La principal diferencia entre los comandos es que los usuarios no pueden invalidar las versiones del paquete especificadas ennpm-shrinkwrap.json
. Además, el archivonpm-shrinkwrap.json
es compatible con versiones anteriores de npm (versiones 2-4), mientras quepackage-lock.json
es compatible con npm versión 5 y posteriores. Por lo tanto, puede encontrarnpm-shrinkwrap.json
al mantener los código base heredados. La mayoría de los desarrolladores usaránpackage-lock.json
en lugar denpm-shrinkwrap.json
. Una excepción en la que se prefierenpm-shrinkwrap.json
es para las instalaciones globales de demonios y herramientas de línea de comandos en las que los desarrolladores desean asegurarse de que se instalan las versiones exactas de los paquetes especificados.
Ejemplo de determinación de la versión del paquete
Imagine que usa la versión 1.2 en el código y, luego, se publica la versión 1.4 y se interrumpe el código. Si alguien instala la aplicación en este momento, obtendrá una aplicación que no funciona. Sin embargo, si hay un archivo package-lock.json
que especifica la versión 1.2, esa versión se instalará.
Este es un ejemplo de cómo determinar la versión instalada de un paquete:
- Si los archivos
package.json
ypackage-lock.json
coinciden en una regla de versión, no hay ningún conflicto. Por ejemplo, sipackage.json
especifica1.x
ypackage-lock.json
especifica la versión 1.4, se instalará la versión 1.4. - Si
package.json
especifica una versión más específica, como1.8.x
, invalida el archivopackage-lock.json
, que indica la versión anterior de 1.4. En este caso, se instalará la versión 1.8.0 o una versión de revisión posterior, si existe.
Búsqueda y actualización de paquetes obsoletos con npm obsoleto
El comando npm outdated
se usa para identificar los paquetes con versiones más recientes disponibles. Cuando se ejecuta, proporciona una lista de estos paquetes obsoletos:
Package Current Wanted Latest Location Depended by
lodash 1.0.0 1.0.0 4.17.19 lock-test main-code-file
node-fetch 1.2.0 1.2.0 2.6.0 lock-test function-code-file
Las columnas de la salida incluyen lo siguiente:
Columna | Descripción |
---|---|
Paquete | El paquete obsoleto. |
Actuales | La versión instalada actual del paquete. |
Deseado | La versión más reciente que coincide con el patrón semántico especificado en el archivo package.json . |
Más reciente | La versión más reciente del paquete. |
Location | La ubicación de la dependencia del paquete. El comando outdated rastrea todos los paquetes instalados en las diversas carpetas node_modules . |
Dependiente | El paquete que tiene la dependencia. |
Administración de incidencias de seguridad con npm audit
Cada vez que instale o actualice un paquete, obtendrá una respuesta de registro que indica qué versión se instaló y si hay alguna vulnerabilidad. En el registro se enumeran las vulnerabilidades. Si se detecta alguna vulnerabilidad crítica o de nivel alto, debería actualizar el paquete.
Un ejemplo de respuesta de registro es:
+ lodash@1.3.1
added 1 package from 4 contributors and audited 1 package in 0.949s
found 3 vulnerabilities (1 low, 2 high)
run `npm audit fix` to fix them, or `npm audit` for details
Para corregir un problema y aplicar una actualización, puede ejecutar el comando npm audit
. Este comando enumera cada vulnerabilidad.
El comando npm audit fix
intenta resolver las vulnerabilidades mediante la actualización a una versión secundaria en la que el problema no existe. Sin embargo, es posible que no esté disponible si la corrección se encuentra realmente en la siguiente versión principal.
En tales casos, tal vez tenga que usar npm audit fix --force
, que puede introducir cambios importantes mediante la actualización a la versión principal. La ejecución de este comando es una decisión que no debería tomar a la ligera. Debe tener en cuenta los cambios importantes y usar npm update
para actualizar el código, incluidas las vulnerabilidades.
Una vulnerabilidad es un error de código que los atacantes pueden aprovechar para realizar acciones malintencionadas, lo que puede poner en riesgo los datos y sistemas. Es fundamental abordar estas vulnerabilidades rápidamente.
Dada la frecuente detección de vulnerabilidades, GitHub tiene una característica que examina los repositorios y crea solicitudes de cambios de forma automática en las que se sugieren actualizaciones a versiones más seguras. Ejecutar npm audit
con regularidad es un procedimiento recomendado para identificar y corregir vulnerabilidades, lo que contribuye a la seguridad general del proyecto.
Flujo de trabajo de actualización recomendado
El flujo de trabajo recomendado para las actualizaciones es:
npm run test
: compruebe que las pruebas existentes se pasan antes de iniciar este proceso de actualización.npm audit
: para comprobar si hay vulnerabilidades en la versión actual que usa. En la información denpm audit
es posible que se recomiende la actualización a una versión principal. Debe revisar cuidadosamente los cambios importantes si se enumeran.npm outdated
: para enumerar todos los paquetes obsoletos. Este comando proporciona información en las columnas Deseado, Último y Ubicación.- Actualice con
npm update
:- Para proyectos más pequeños (algunas dependencias en
package.json
: puede probarnpm update
para actualizar todas las dependencias y, a continuación, ejecutar las pruebas. - Para proyectos más grandes (con muchas dependencias en
package.json
: actualice un único paquete o una familia de paquetes (como Next.js y React) y, a continuación, ejecute las pruebas.
- Para proyectos más pequeños (algunas dependencias en
npm audit
: compruebe que no hay vulnerabilidades críticas o de nivel alto. Si todavía hay vulnerabilidades, usenpm update
con el nombre del paquete y la versión principal recomendada ennpm audit
.npm run test
otra vez.- Proteja
package.json
ypackage-lock.json
.