Un análisis en profundidad del archivo package.json

Comprender package.json

Debajo del directorio raíz de cada proyecto (paquete descargado de npm u otros proyectos de nodejs), generalmente hay un archivo package.json, que define los diversos módulos necesarios para el proyecto, así como la información de configuración del proyecto ( Metadatos como nombre, versión, licencia, cómo iniciar el proyecto, ejecutar scripts, etc.). El comando npm install descarga automáticamente los módulos necesarios según este archivo de configuración.

El archivo package.json es un objeto JSON y cada miembro del objeto es una configuración del proyecto actual. Por ejemplo, name es el nombre del proyecto version es la versión (siguiendo el formato de "versión principal.versión menor.versión menor"). También desempeñará múltiples funciones en el ciclo de vida del proyecto, incluido el desarrollo, las pruebas y las versiones en línea.

package.json funciona

• como un archivo de descripción que describe los paquetes de los que depende su proyecto.
• Nos permite usar "reglas de control de versiones semánticas" (descritas más adelante) para indicar la versión de los paquetes dependientes de su proyecto
• para que su compilación pueda comunicarse mejor con otros desarrolladores. Comparta para facilitar su reutilización

Cómo crear package.json

1. Utilice la herramienta de línea de comando CLI

npm init.

Esto iniciará el cuestionario de línea de comando, que creará package.json en el directorio donde inició el comando.

Entrada de front-end (vue) al curso de dominio: Ingrese al aprendizaje

2. Cree el valor predeterminado

Para obtener el valor predeterminado package.json , ejecute npm init con --yes o -y :

npm init -y

Este método usará package.json del actual. La información extraída del directorio genera valores predeterminados, omitiendo el paso de responder preguntas.

3. Cree manualmente

un nuevo archivo package.json directamente en el directorio raíz del proyecto y luego ingrese el contenido relevante. Consulte las notas en package.json a continuación para obtener más detalles.

Explicación detallada de los campos comunes en los archivos package.json

1. El nombre

es un campo obligatorio, que es el nombre del módulo/paquete actual. La longitud debe ser menor o igual a 214 caracteres. No puede comenzar con "." ) o "_" (guión bajo) y no puede contener letras mayúsculas.

Este nombre se puede pasar como parámetro a require(), por lo que debe ser corto, pero aún así significativo.

2. La versión

es un campo obligatorio, el número de versión del paquete actual, el valor predeterminado es 1.0.0 cuando se crea por primera vez.

La versión debe poder resolverse mediante un módulo node-semver del que depende npm. Define el progreso de la iteración de la versión del proyecto actual. (Siga el formato de "versión principal. Versión menor. Versión menor")

Quizás muchos amigos ahora no presten atención o no les importe el número de versión y prefieran usar el número de versión del producto o el git. método de código hash.

3. El

campo opcional de descripción debe ser una cadena. La información de descripción del paquete actual es una cadena. Ayuda a las personas a encontrar el paquete cuando utilizan la búsqueda npm.

Si no hay información description en package.json, npm usa la primera línea de README.md en el proyecto como información de descripción. Esta información de descripción ayudará a otros a buscar su proyecto, por lo que se recomienda escribir bien description .

4. El

campo opcional principal especifica el archivo de entrada para la carga del proyecto.

El valor predeterminado de este campo es index.js en el directorio raíz del módulo.

5. El

campo opcional scripts es un objeto hash compuesto por comandos de script que se ejecutan en diferentes ciclos de vida del paquete. La clave es el evento del ciclo de vida y el valor es el comando que se ejecutará. Especifica la abreviatura de la línea de comando npm para ejecutar el comando de script. Por ejemplo, start especifica el comando que se ejecutará al ejecutar npm run start. Podemos personalizar el comando que queremos para ejecutar el script.

Referencia: http://www.ruanyifeng.com/blog/2016/10/npm_scripts.html

script de ejecución de configuración de scripts

)

• Ejecute el comando echo xxx

• 2. para ejecutar el archivo en node_modules/.bin.

Cuando ejecuto npm run, se creará automáticamente un nuevo Shell y el comando de script especificado se ejecutará en este Shell. Por lo tanto, siempre que Shell (generalmente Bash) pueda ejecutar el comando, se puede escribir en el script npm. También copiará node_modules/.bin en el directorio actual a la ruta del sistema actual (es solo una copia temporal. Una vez completada la ejecución, la variable PATH se restaurará a su estado original), por lo que todos los scripts en node_modules /.bin subdirectorio del directorio actual. Se puede llamar a Todo directamente usando el nombre del script sin agregar una ruta.

Por ejemplo:

si usamos node para ejecutar un servicio node.js, node + 文件puede usar node server.js . También podemos usar webpack para empaquetar el archivo front-end, webpack-dev-server . Por supuesto, webpack y. Es necesario instalar webpack-dev-server. Módulos dependientes;

"scripts": {   
    "build": "webpack --mode=desarrollo",
    "dev": "webpack-dev-server --mode=desarrollo --contentBase=./dist",
    "servidor": "nodo app.js"
  }

Ingresamos npm run server en la herramienta de línea de comando y se llamará al nodo app.js para ayudarnos a ejecutarlo.

Forma abreviada:

npm start es npm run start
npm stop es la abreviatura de npm run stop npm test es la abreviatura de npm run test npm restart es la abreviatura de npm run stop && npm run restart && npm run start

Scripts de uso común ----- Transferencia de colección en línea

// Eliminar directorio "clean": "rimraf dist/*",

// Construye un servicio HTTP "servido" localmente: "http-server -p 9090 dist/",

//Abre el navegador "open:dev": "opener http://localhost:9090",

//Actualiza "livereload" en tiempo real: "live-reload --port 9091 dist/",

// Construye el archivo HTML "build:html": "jade index.jade > dist/index.html",

// Mientras el archivo CSS cambie, vuelva a ejecutar la compilación "watch:css": "watch 'npm run build:css' activos/estilos/",

// Mientras el archivo HTML cambie, vuelva a ejecutar la compilación "watch:html": "watch 'npm run build:html' activos/html",

//Implementar en Amazon S3
"deploy:prod": "s3-cli sync ./dist/ s3://example-com/prod-site/",

//Construir favicon
"build:favicon": "scripts de nodo/favicon.js",

"start": "cross-env NODE_ENV = servidor de nodo de producción/index.js",

6. dependencias y devDependencies

son campos opcionales. El campo de dependencies especifica los módulos de los que depende el proyecto y devDependencies especifica los módulos necesarios para el desarrollo del proyecto.

El valor apunta a un objeto. Cada miembro de este objeto consta del nombre del módulo y el requisito de versión correspondiente, indicando el módulo dependiente y su rango de versiones.

No hay ningún paquete.json creado de forma predeterminada, se generará cuando instalemos npm install un módulo.

instalación npm expresa
npm instalar express --guardar
npm install express --save-dev

El código anterior significa instalar el módulo express por separado.

• Cuando no hay parámetros detrás de él, significa instalarlo en dependencies .
El parámetro --save significa escribir el módulo en las dependencias. atributo.
• --save-dev significa escribir el módulo
• --save dependencies .
Ingrese el atributo devDependencies .

7.

Campo opcional BundledDependencies, otras dependencias se empaquetan al mismo tiempo que se publica el paquete.

8. campo opcional peerDependencies

, dependencia de compatibilidad, si su proyecto o módulo depende de otro módulo al mismo tiempo, pero la versión de la que depende es diferente.

Por ejemplo, su proyecto depende de la versión 1.0 del módulo A y del módulo B, y el módulo A depende de la versión 2.0 del módulo B.

{
  "nombre": "chai-como-prometió",
  "peerDependencies": {
    "chai": "1.x"
  }
}

El código anterior especifica que al instalar el módulo chai-as-promised , el programa principal chai debe instalarse junto y la versión chai debe ser 1.x Si la dependencia especificada por su proyecto es la versión 2.0 de chai , se informará un error.

9.

Campo opcional bin El campo bin se utiliza para especificar la ubicación del archivo ejecutable correspondiente a cada comando interno.

Cree el archivo /bin/www en el directorio raíz del proyecto

Configure

"bin"

/usr/bin/env node

  "lee-cli":"./bin/www"
}

npm link agrega la ruta del valor del atributo bin en el paquete a un enlace global, crea una conexión de acceso directo y

ejecuta lee-cli en la línea de comando para ejecutar el archivo bin/www. El proceso es:

En el ejemplo anterior, www creará un enlace simbólico node_modules/.bin/www . Dado que el directorio node_modules/.bin/ se agregará a la variable PATH del sistema en tiempo de ejecución, estos scripts se pueden llamar directamente mediante comandos sin una ruta cuando se ejecuta npm.

10. config

El campo de configuración se utiliza para generar valores en variables de entorno

{
  "nombre": "paquete",
  "config": {"puerto": "8080" },
  "scripts": { "inicio": "node server.js" }
}

Si queremos cambiarlo, podemos usar

el paquete npm config set: puerto 80

11. El

campo opcional de motores especifica la versión de la plataforma en la que se ejecuta el módulo, como una determinada versión de Node o un navegador. versión npm aplicable.

"motores": { 
"nodo": 
">=0,10,3 <0,12"
}

12. Campo opcional Licencia

, que indica la definición de la licencia aplicable al código descrito en package.json. Diferentes protocolos tienen diferentes restricciones. Informe a los usuarios qué permisos tienen para usar su módulo y qué restricciones existen para usarlo.

Consulte: elijaalicense.com/ para elegir una licencia.

Por ejemplo: MIT: permiso máximo, otros pueden cambiar su código después de descargarlo, valor de instalación predeterminado.

Campo opcional

Autor

14.

Campo opcional privado, valor booleano, ya sea privado. Cuando se establece en verdadero, npm se niega a publicar.

Esta es una forma de evitar que los paquetes privados se entreguen a personas externas. Si desea empaquetar un paquete para publicarlo solo en un registro específico (por ejemplo, un registro interno), puede usar la descripción del diccionario PublishConfig a continuación para anular los parámetros de configuración del registro en el momento de la publicación.

15. El

campo opcional de palabras clave, palabras clave del proyecto, es una matriz de cadenas. Ayuda a las personas a encontrar el paquete cuando utilizan la búsqueda npm.

16. El

campo opcional os especifica el sistema operativo en el que se puede ejecutar el módulo.

17. estilo estilo

especifica la ubicación del archivo de estilo cuando lo utiliza el navegador.

18.

El tipo de lugar donde se almacena el código del paquete del repositorio puede ser git o svn. git puede estar en Github

19. El

campo opcional de la página de inicio no tiene URL con prefijos de protocolo como http://.

Problema de versión:

versión: "1.0.0"

1.0.0:

el cambio del primer dígito significa: incompatibilidad con el código anterior, actualización a gran escala, lanzamiento de una nueva versión;

el segundo dígito significa: se han agregado algunas funciones,

la tercera

es compatibilidad con versiones anteriores;

dígito

significa: se han agregado algunas funciones, bit de compatibilidad con versiones anteriores

significa: parches pequeños, correcciones de errores

cuando publicamos el proyecto, usamos npm + git

• para usar npm version patch (parche de parche). ; use git tag para ejecutar y estará automáticamente en git
• Use npm version minor para cambiar el segundo dígito del número de versión; sincronice la versión de git
• npm version major ;

versión npm [<nuevaversión> | mayor | parche menor | prelanzamiento previo |

principal: número de versión principal menor: número de versión menor parche: número de parche premayor: versión principal preliminar parche previo: versión menor preliminar prelanzamiento: versión preliminar

ps: Nota, si se informa un error: el directorio de trabajo de Git no está limpio, significa que Necesito git status para estar limpio ahora.

git agregar.
git commit -m "explicación detallada de paquete.json"

npm versin monir -m"增加版本号"

git push -u origin master ¿

Cómo formular reglas?

Como usuarios, podemos indicar en el archivo package.json cuántas actualizaciones podemos aceptar para este paquete (suponiendo que actualmente confiamos en la versión 1.2.4):

• Si solo pretendemos aceptar actualizaciones de la versión del parche (es decir, el último dígito cambia), puedes escribirlo así:

  1.2
   1.2.x
   ~1.2.4

• Si acepta actualizaciones de versión menores (cambios en la segunda posición), puede escribir así:

  1
  1.x
  ^1.2.4

• Si puede aceptar actualizaciones de versiones principales (naturalmente, acepte cambios de versiones menores y de parches), puede escribir así:

  *x

  Para resumir: hay tres tipos de cambios de versión, qué tipo de actualización de paquetes dependientes se acepta ? Escriba el número de versión con precisión en el dígito anterior.

Ciclo de versión y etapas:

• α-Alpha La primera fase generalmente es solo para pruebas internas
• β-Beta La segunda fase ha eliminado la mayoría de las imperfecciones en el software, pero aún puede haber defectos y lagunas, y generalmente se proporciona para pruebas específicas.

de

2.1.0-beta.1

• .
• En este momento, el producto está bastante maduro y solo necesita optimizarse aún más en algunos lugares antes de que pueda lanzarse al mercado.

2.1.0-beta.1 es generalmente utilizado por usuarios como este. Este tipo de cosas no se instalarán. Este tipo puede ser utilizado por internos y evaluadores.

¿Diferenciar entre instalar Dependencies y dependencies ?

devDependencies son módulos necesarios para el desarrollo, por lo que podemos instalarlos según sea necesario durante el proceso de desarrollo para mejorar nuestra eficiencia de desarrollo, como algunas bibliotecas de terceros conocidas, webpack , rollUp , less , babel , etc. No es necesario instalarlo en el entorno de producción.

Se recomienda instalar las siguientes bibliotecas en devDependencies :

• compatibilidad con pruebas unitarias (mocha, chai)
• compatibilidad
• de
• sintaxis (babel);
• webpack, gulp, grunt, uglifyJS);
• procesador css (postCSS, SCSS,
• especificación de código Stylus (eslint);

paquete de dependencia (especificar, actualizar, local, usar, desinstalar)

1. Instalar el paquete de dependencia local

npm install jquery

Este comando Cree un directorio node_modules en el directorio actual y luego descargue el paquete que especificamos en este directorio.

2. Para especificar la versión de instalación, puede @版本号después del nombre del paquete.

Si el nombre de un paquete comienza con paquete @ , es un paquete con ámbito .

npm instala [email protected]
npm instala jquery@">=1.1.0 <2.2.0"

npm install jquery@latest

, el número de versión en las dependencias también cambiará.

3. Actualice el paquete dependiente

npm update jquery

4. Utilice el paquete

let jquery = require('jquery');

<script src="/node_modules/jquery/dist/jquery.js">//Esto debe prestar atención a ruta</script>

6, desinstale el paquete dependiente

npm uninstall jquery

Versionado semántico (reglas de control de versiones semánticas)

• https://docs.npmjs.com/about-semantic-versioning

• https://github.com/npm/node-semver

paquete .json Notas

según lo anterior Cuando usamos npm init se nos pedirá que completemos varios elementos. Algunos de ellos son opcionales y otros son obligatorios. Estos campos obligatorios son todos los campos que debe tener el contenido de un package.json : name y. version De lo contrario, install no se puede ejecutar

• nombre: todo en minúsculas, sin espacios, use guiones y guiones bajos en secuencia
• versión: número de versión, siga las reglas de control de versiones semánticas mencionadas anteriormente xxx

Otras notas:

• agregar comentarios en chino provocará errores de compilación.