¿Cómo puedo especificar la versión requerida de Node.js en package.json?


261

Tengo un proyecto Node.js que requiere Node versión 12 o superior. ¿Hay alguna forma de especificar esto en el archivo packages.json, para que el instalador verifique e informe a los usuarios automáticamente si necesitan actualizar?


1
Una forma similar a la respuesta de Adam, también usando node.version: stackoverflow.com/a/48691987/3032209
Yair Kukielka


La pregunta ya se hizo aquí: ¿Cómo aplicar una versión específica de node.js para usar?
cilap

Me pregunto si hay alguna herramienta que pueda establecer automáticamente este campo en un valor apropiado al inspeccionar el uso de la API.
geekley

Respuestas:


288

Creo que puedes usar el campo "motores":

{ "engines" : { "node" : ">=0.12" } }

Como está diciendo que su código definitivamente no funcionará con ninguna versión anterior, probablemente también desee el indicador "engineStrict":

{ "engineStrict" : true }

La documentación para el archivo package.json se puede encontrar en el sitio npmjs

Actualizar

engineStrictahora está en desuso, por lo que esto solo dará una advertencia. Ahora depende del usuario ejecutar npm config set engine-strict truesi quiere esto.

Actualización 2

Como señaló Ben a continuación, la creación de un .npmrcarchivo en la raíz de su proyecto (el mismo nivel que su archivo package.json) con el texto engine-strict=trueforzará un error durante la instalación si la versión del Nodo no es compatible.


13
github.com/npm/npm/blob/master/CHANGELOG.md#enginestrict "La opción package.json raramente utilizada engineStrictha quedado en desuso durante varios meses, produciendo advertencias cuando se usó. Comenzando con npm @ 3, el valor de se ignora el campo, y las violaciones del motor solo producirán advertencias. Si, como usuario, desea una aplicación estricta del campo de los motores, simplemente ejecute npm config set engine-estricto verdadero "
Mike Stead

1
Recuerde hacerlo cd .. && npm i <folder-name>para verificar el proyecto en sí. Sin embargo, esto desencadenará una construcción completa en sí mismo.
mlunoe

66
por qué en la tierra desaprobaron eso ... pierde todo su significado entonces
vasilakisfil

15
Agregar engine-strict=truea su .npmrc ahora tiene el mismo efecto
ben

44
@ben Perfecto, gracias! Y esto se puede comprometer para que al menos todo su equipo deba cumplir con los requisitos de la versión del motor.
Joshua Pinter el

115

Añadir

a package.json

  "engines": {
    "node": ">=10.0.0",
    "npm": ">=6.0.0"
  },

al archivo .npmrc(cerca del package.jsonmismo directorio)

engine-strict=true

3
Esta es la solución más fácil que le da al usuario final un gran error sobre no tener la versión correcta del nodo cuando se ejecuta npm install; trabaja con yarnasí
jcollum

1
Esto parece no tener ningún efecto en absoluto. Configuré mi package.jsoncon una sección de "motores" similar a la anterior ( 11.13.0y 6.7.0), y una .npmrccon nada más que el contenido especificado anteriormente. Nvm me cambió a una versión de nodo anterior, luego ejecuté npm install, pero solo instala las dependencias y ni siquiera menciona la falta de coincidencia de la versión del motor.
Adrian

54

Al igual que dijo Ibam, engineStrictahora está en desuso. Pero he encontrado esta solución:

check-version.js:

import semver from 'semver';
import { engines } from './package';

const version = engines.node;
if (!semver.satisfies(process.version, version)) {
  console.log(`Required node version ${version} not satisfied with current version ${process.version}.`);
  process.exit(1);
}

package.json:

{
  "name": "my package",
  "engines": {
    "node": ">=50.9" // intentionally so big version number
  },
  "scripts": {
    "requirements-check": "babel-node check-version.js",
    "postinstall": "npm run requirements-check"
  }
}

Obtenga más información aquí: https://medium.com/@adambisek/how-to-check-minimum-required-node-js-version-4a78a8855a0f#.3oslqmig4

.nvmrc

Y una cosa más. Se puede usar un archivo de puntos '.nvmrc' para requerir una versión de nodo específica: https://github.com/creationix/nvm#nvmrc

Pero, solo es respetado por los scripts npm (y los scripts de hilo).


2
Esta es la mejor respuesta en 2019, a la luz de la depreciación establecida del motor y la realidad de que muchos (probablemente) se encuentran con esto debido al cambio de versiones con nvm.
artesanal

14

.nvmrc

Si está utilizando NVM de esta manera , lo que probablemente debería, entonces puede indicar la versión de nodejs requerida para un proyecto determinado en un .nvmrcarchivo con seguimiento de git :

echo v10.15.1 > .nvmrc

Esto no tiene efecto automáticamente cd, lo cual es sensato: el usuario debe hacer lo siguiente:

nvm use

y ahora esa versión del nodo se usará para el shell actual.

Puede enumerar las versiones de nodo que tiene con:

nvm list

.nvmrcestá documentado en: https://github.com/creationix/nvm/tree/02997b0753f66c9790c6016ed022ed2072c22603#nvmrc

cdSe preguntó cómo seleccionar automáticamente la versión de ese nodo en: Cambiar automáticamente a la versión correcta del Nodo según el proyecto

Probado con NVM 0.33.11.


8

Hay otra forma más simple de hacer esto:

  1. npm install Node@8 (guarda el Nodo 8 como dependencia en package.json)
  2. Su aplicación se ejecutará utilizando el Nodo 8 para cualquier persona , ¡incluso para usuarios de Yarn!

Esto funciona porque nodees solo un paquete que envía el nodo como paquete binario. Solo incluye como node_module / .bin, lo que significa que solo hace que el nodo esté disponible para empaquetar scripts. No es la carcasa principal.

Vea la discusión en Twitter aquí: https://twitter.com/housecor/status/962347301456015360


55
No estoy de acuerdo, esto podría ocultar el problema y generaría una versión diferente del nodo si no estuviera instalado.
Brendan Hannemann

77
-1 porque esta es una idea terrible (realmente terrible). Es como decir que si está desempleado, primero debe financiar una empresa y comenzar a trabajar allí.
ozanmuyes

2
Suena como una gran idea para mí. Versiones de nodo separadas para proyectos separados. Puede actualizar uno de forma segura sin actualizar los otros. Solo catch tiene que ejecutarse en .bin en ./node node-sasslugar de solo node-sass. No estoy seguro si es igual para todos los archivos .bin.
Jon

2
Esta es una solución simple y elegante, siempre y cuando los miembros del equipo que trabajan en el producto sepan que esto está sucediendo, creo que es una gran respuesta. Estamos utilizando esta técnica en una gran empresa para hacer frente a la variedad de versiones de Node para una docena de productos front-end web. Elimina la necesidad de un cambio constante con nvm al ir y venir entre productos.
Nathan Bedford

2
Esta solución tiene sus propios pros y contras. La encapsulación de la versión de nodo es potencialmente su mayor profesional. La desventaja es el tamaño de la imagen acoplada hinchada si va a implementarlo de esta manera.
ivosh

0

Un ejemplo de caso de prueba Mocha:

describe('Check version of node', function () {
    it('Should test version assert', async function () {

            var version = process.version;
            var check = parseFloat(version.substr(1,version.length)) > 12.0;
            console.log("version: "+version);
            console.log("check: " +check);         
            assert.equal(check, true);
    });});

1
No debería ser una prueba unitaria, use package.json / dotfiles
bgcode del

2
Pero por qué, una prueba de unidad está diseñada para esto> .-
Jamie Nicholl-Shelley

Porque necesita Node para ejecutar una prueba unitaria. Si la versión del nodo actual está demasiado desactualizada, las pruebas simplemente no se ejecutarán o fallarán con un error de sintaxis o algo. similar, que derrota el punto de las pruebas unitarias. Es como ocultar un formulario de restablecimiento de contraseña detrás de un formulario de autorización. Si no puede recordar la contraseña, debe usar la función de restablecimiento de contraseña, pero ahora no puede usarla, porque no recuerda la contraseña.
ankhzet
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.