configuración de package.json

Si va a desarrollar una aplicación de Node.js con una gran cantidad de paquetes npm, no es raro que se produzcan advertencias o errores al compilar el proyecto si se han actualizado uno o varios paquetes. A veces, se produce un conflicto de versión o una versión del paquete ha sido marcada como obsoleta. Estos son un par de sugerencias rápidas que le ayudarán a configurar el archivo package.json y comprender lo que está ocurriendo cuando vea advertencias o errores. Esta no es una guía completa para package.json y solo se centra en el control de versiones del paquete npm.

El sistema de control de versiones de paquetes npm tiene reglas estrictas. El formato de versión sigue aquí:

[major].[minor].[patch]

Supongamos que tiene un paquete en la aplicación con una versión de 5.2.1. La versión mayor es 5, la versión menor es 2, y el parche es 1.

• En una actualización de versión principal, el paquete incluye nuevas características que no son compatibles con versiones anteriores, es decir, cambios disruptivos.
• En una actualización de versión secundaria, se han agregado nuevas características al paquete que son compatibles con versiones anteriores del paquete.
• En una actualización de revisión, se incluyen una o varias correcciones de errores. Las correcciones de errores siempre son compatibles con versiones anteriores.

Vale la pena tener en cuenta que algunas características del paquete npm tienen dependencias. Por ejemplo, para usar una nueva característica del paquete del compilador de TypeScript (ts-loader) con webpack, es posible que también necesite actualizar el paquete npm de webpack y el paquete webpack-cli.

Para ayudar a administrar el control de versiones de paquetes, npm admite varias notaciones que puede usar en el package.json. Puedes usar estas notaciones para controlar el tipo de actualizaciones de paquete que quieres aceptar en tu aplicación.

Supongamos que usa React y necesita incluir el paquete react y react-dom npm. Puede especificarlo de varias maneras en el archivo package.json . Por ejemplo, puede especificar el uso de la versión exacta de un paquete como se indica a continuación.

"dependencies": {
  "react": "16.4.2",
  "react-dom": "16.4.2",
},

Con la notación anterior, npm siempre obtendrá la versión exacta especificada, 16.4.2.

Puede usar una notación especial para limitar las actualizaciones a las actualizaciones de revisión (correcciones de errores). En este ejemplo:

"dependencies": {
  "react": "~16.4.2",
  "react-dom": "~16.4.2",
},

Se usa el carácter tilde (~) para indicar a npm que solo actualice un paquete cuando se aplique la revisión. Por lo tanto, npm puede actualizar react 16.4.2 a 16.4.3 (o 16.4.4, etc.), pero no aceptará una actualización a la versión principal o secundaria. Por lo tanto, 16.4.2 no se actualizará a 16.5.0.

También puede usar el símbolo de intercalación (^) para especificar que npm puede actualizar el número de versión secundaria.

"dependencies": {
  "react": "^16.4.2",
  "react-dom": "^16.4.2",
},

Con esta notación, npm puede actualizar react 16.4.2 a 16.5.0 (o 16.5.1, 16.6.0, etc.), pero no aceptará una actualización de la versión principal. Por lo tanto, 16.4.2 no se actualizará a 17.0.0.

Cuando npm actualiza los paquetes, genera un archivo package-lock.json , que enumera las versiones reales del paquete npm usadas en la aplicación, incluidos todos los paquetes anidados. Aunque package.json controla las dependencias directas de la aplicación, no controla las dependencias anidadas (otros paquetes npm requeridos por un paquete npm determinado). Puede usar el archivo package-lock.json en el ciclo de desarrollo si necesita asegurarse de que otros desarrolladores y evaluadores usen los paquetes exactos que usa, incluidos los paquetes anidados. Para obtener más información, consulte package-lock.json en la documentación de npm.

Para Visual Studio, el archivo package-lock.json no se agrega al proyecto, pero puede encontrarlo en la carpeta del proyecto.