nombre
Hasta que publiquemos el paquete en el repositorio, el campo también se puede puntuar. La pregunta es que este campo es conveniente para nombrar el archivo de instalación o, por ejemplo, para mostrar el nombre del producto en su página web. En general, "¿cómo se llama un yate, .."
version
La idea principal es no olvidar aumentar el número de versión mientras se expande la funcionalidad, se corrigen errores, ... Desafortunadamente, en nuestra oficina aún puede encontrar productos con la versión sin cambios 0.0.0. Y luego adivina qué tipo de funcionalidad funciona para el cliente ...
principal
Este
campo indica qué archivo se iniciará cuando se inicie nuestra aplicación (`npm start`). Si el paquete se usa como una dependencia, entonces qué archivo se importará al usar nuestro módulo por otra aplicación. El directorio actual es el directorio donde se encuentra el archivo `package.json`.
Y también, si, por ejemplo, usamos
vscode , el archivo especificado en este campo se iniciará cuando se llame al depurador o cuando se ejecute el comando "ejecutar".
La extensión ".js" puede omitirse. Es más bien una consecuencia de todos los casos de uso posibles, por lo que no se detalla directamente en la documentación.
motores
Este campo contiene la tupla: {"nodo":
versión , "npm":
versión , ...}.
Conozco los campos "nodo" y "npm". Determinan las versiones de node.js y npm necesarias para que nuestra aplicación funcione. Las versiones se comprueban ejecutando el comando npm install.
Se admite la sintaxis estándar para determinar la versión de los paquetes de dependencia: sin un prefijo (versión única), el prefijo "~" (los dos primeros números de la versión deben coincidir) y el prefijo "^" (solo el primer número de la versión debe coincidir). Si hay un prefijo, la versión debe ser mayor o igual que la especificada en este campo. Solo una lista de versiones; indicación explícita más, menos, ... etc. También funciona.
Descargo de responsabilidad "Npm install" verifica las versiones especificadas en los "motores" solo si el modo "motor estricto" está habilitado. Lo incluimos para cada proyecto, agregando el archivo .npmrc con la línea: "engine-strictly = true". Érase una vez, "npm install" hizo esta verificación por defecto.
Algunos contenedores, al menos en la documentación, escriben que las versiones adecuadas se utilizarán por defecto. En este caso, estamos hablando de Azure.
Un ejemplo:
"engines": { "node": "~8.11",
"rastrillo" regular
¡Y el rey está desnudo!
Se acordó repetidamente con el cliente que la versión requerida de `node.js` debería ser al menos 8. Cuando se entregaron las versiones iniciales de la aplicación, todo funcionó. "Un día" después de la entrega de la nueva versión en el cliente, la aplicación dejó de ejecutarse. Todo funcionó en nuestras pruebas.
El problema era que en esta versión comenzamos a usar funcionalidades que solo eran compatibles con la versión 8 node.js. El campo "motores" no estaba lleno, por lo que nadie había notado antes que el cliente tenía una versión antigua de node.js. (Servicios web de Azure predeterminados).
guiones
El campo contiene una tupla de la forma: {"script1":
script1 , "script2":
script2 , ...}.
Hay scripts estándar que se ejecutan en una situación dada. Por ejemplo, el script "instalar" se ejecutará después de ejecutar "npm install". Es muy conveniente, por ejemplo, verificar la disponibilidad de los programas necesarios para que la aplicación funcione. O, por ejemplo, comprimir todos los archivos estáticos disponibles a través de nuestro servicio web para que no tengan que comprimirse sobre la marcha.
En este caso, no puede limitarse solo a los nombres estándar. Para ejecutar un script arbitrario, debe ejecutar "npm run
script-name ".
Es conveniente recopilar todos los scripts usados en un solo lugar.
Un ejemplo:
"scripts": { "install": "node scripts/install-extras", "start": "node src/well/hidden/main/server extra_param_1 extra_param_2", "another-script": "node scripts/another-script" }
PD La extensión ".js" se puede omitir en la mayoría de los casos.