el formato de versiónEntrada de front-end (vue) al curso de competencia: ingrese para aprender
: XYZ[-string]
6.3.2-alpha
significado
es
:
Iteraciones actualizadas compatiblesVersión menor número 3, hay 3 pequeñas iteraciones de funciones. Este nuevo paquete se puede instalar para cualquier declaración de dependencia de 6.*.*
<= 6.3.2
.
Versión corregida número 2, hay 2 modificaciones de errores u otras modificaciones funcionales no importantes. Este nuevo paquete se puede instalar para cualquier declaración de dependencia de 6.*.*
<= 6.3.2
.
El número de versión avanzada alpha
representa la etapa experimental de procesamiento.
Lectura ampliada: Cómo identificar versiones de dependencia en la versión semántica 2.0.0
se explicará de la siguiente manera:
"vue": "~2.5.22", "vue-class-component": "^6.0.0", "vue-enrutador": "3.0.1", "expreso": "último", "mongoose": "*",
símbolo ^
: bloquea la versión principal, puede actualizar el número de versión secundaria, el número de versión revisada y el número de versión avanzada.
Por ejemplo "vue-class-component": "^6.0.0"
. puede instalarlo al instalar dependencias. Cualquier versión que se ajuste a 6.*.*
, siempre que el número de versión principal sea 6.
Símbolo ~
: Bloquee el número de versión principal y el número de versión secundaria, y actualice el número de versión revisada y el número de versión anterior,
como "vue": "~2.5.22"
Al instalar dependencias, puede instalar cualquier versión que se ajuste a 2.5.*
.
空符号
: bloquea todos los números de versión,
como "vue-router": "3.0.1"
, y solo se pueden instalar paquetes dependientes con la versión 3.0.1
.
符号*
: define un cierto rango de números de versión,
como vue-router": "3.0.*"
, puede instalar cualquier versión fijada en 3.0
, como 3.0.1
, 3.0.2
.
latest
: instala la última versión estable.
Por ejemplo, "express": "latest"
puede instalar 4.18.1
(la última versión 2022.06.13).
*
: Instale la última versión lanzada, no necesariamente la versión estable
Por ejemplo, "mongoose": "*"
puede instalar 6.0.0-rc2
, 3.9.7
, etc.
Git URL
: utilice el formato de referencia del paquete publicado en Git
: <protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit-ish> | #semver:<semver>]
"test": "git+ssh://[email protected]:npm/cli.git#v1.0.27"
Lectura ampliada: npm docs -
Como dice el título, esta es una experiencia adquirida a través de lecciones de sangre.
Cuando el autor usa system.js
, el límite de versión utilizado es: system.js: "^6.3.2"
.
Al instalar dependencias, se instaló accidentalmente la versión > 6.3.2
, lo que provocó errores de ejecución del proyecto.
La razón es que el autor de system.js
no nombró el número de versión de acuerdo con la especificación semver
, lo que provocó que el proyecto del autor introdujera una actualización que no era compatible con versiones anteriores , lo que provocó que el proyecto se ejecutara incorrectamente.
utilizadas en el entorno de producción se instalan en dependencies
.
Por ejemplo:
"dependencias": { "tiza": "^2.4.2", "comandante": "^3.0.0", "fs-extra": "^8.1.0", "inquirer": "^6.5.0", "mem-fs": "^1.1.3", "mem-fs-editor": "^6.0.0", "shelljs": "^0.8.3" }
El código anterior es un fragmento del package.json
del kit de herramientas cli
creado por el autor.
shelljs
se utiliza para operar archivos. Si la declaración se cambia a devDependencies
, se informará un error después de que el usuario instale el paquete de herramientas actual.
Porque las dependencias declaradas en el campo devDependencies
no se instalarán cuando npm install 工具包
. Debe declararse en el campo de dependencies
antes de que se instale.
Las dependencias que no son necesarias en el entorno de producción deben instalarse en devDependencies
.
Porque en un entorno de producción, las dependencias del campo devDependencies
no se instalarán.
Por ejemplo:
"devDependencies": { "@commitlint/cli": "^8.1.0", "@commitlint/config-conventional": "^8.1.0", "comprometido": "^4.0.3", "commitlint-config-cz": "^0.12.1", "cz-personalizable": "^6.2.0", "versión estándar": "^7.0.0" }
El código anterior es un fragmento del package.json
del kit de herramientas cli
creado por el autor.
commitizen
es el paquete de dependencia utilizado por el autor para estandarizar las especificaciones de envío Git
. Solo se usa en el entorno de desarrollo, por lo que se declara en devDependencies
.
Al desarrollar algunos complementos y kits de herramientas, existen requisitos para la versión del paquete de dependencia del entorno de ejecución del usuario, que se puede declarar utilizando el campo peerDependencies
.
Por ejemplo:
{ "nombre": "té-latte", "versión": "1.3.5", "peerDependencies": { "té": "2.x" } }
La herramienta actual tea-latte
depende del paquete tea
. Además, se requiere que el paquete tea
sea la versión principal 2.
Cuando no se cumplen los requisitos, la consola informará un error.
Aviso
Versión npm v7, peerDependencies se instalará de forma predeterminada.
npm v3 a npm v6,peerDependencies
no se instalarán automáticamente.