Como posso especificar a versão necessária do Node.js. no package.json?


261

Eu tenho um projeto Node.js que requer o Node versão 12 ou superior. Existe uma maneira de especificar isso no arquivo packages.json, para que o instalador verifique e informe automaticamente os usuários se eles precisam atualizar?


1
Uma maneira semelhante a resposta de Adão, também usando node.version: stackoverflow.com/a/48691987/3032209
Yair Kukielka


A pergunta já foi feita aqui: Como aplicar uma versão node.js específica para uso?
CILAP

Gostaria de saber se existe alguma ferramenta que possa definir automaticamente esse campo para um valor apropriado, inspecionando o uso da API.
geekley

Respostas:


288

Eu acho que você pode usar o campo "engines":

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

Como você está dizendo que seu código definitivamente não funcionará com versões inferiores, você provavelmente também desejará o sinalizador "engineStrict":

{ "engineStrict" : true }

A documentação para o arquivo package.json pode ser encontrada no site npmjs

Atualizar

engineStrictagora está obsoleto, portanto, isso só dará um aviso. Agora cabe ao usuário executar, npm config set engine-strict truese ele quiser.

Atualização 2

Como Ben apontou abaixo, a criação de um .npmrcarquivo na raiz do seu projeto (o mesmo nível do arquivo package.json) com o texto engine-strict=trueforçará um erro durante a instalação se a versão do Nó não for compatível.


13
github.com/npm/npm/blob/master/CHANGELOG.md#enginestrict "A opção package.json raramente usada engineStrictfoi descontinuada por vários meses, produzindo avisos quando foi usada. Começando com npm @ 3, o valor do O campo é ignorado e as violações do mecanismo produzem apenas avisos. Se você, como usuário, deseja uma aplicação estrita do campo dos mecanismos, basta executar o npm config set engine-strict true "
Mike Stead

1
Lembre- cd .. && npm i <folder-name>se de verificar o projeto em si. No entanto, isso desencadeará uma compilação completa em si mesmo.
mlunoe

6
porque na terra que eles reprovada que .. ele perde todo o seu significado, então
vasilakisfil

15
A adição engine-strict=trueao seu .npmrc agora tem o mesmo efeito
ben

4
@ Ben Perfeito, obrigado! E isso pode ser confirmado para que pelo menos toda a equipe seja obrigada a aderir aos requisitos de versão do mecanismo.
Joshua Pinter

115

Adicionar

para package.json

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

para o arquivo .npmrc(próximo ao package.jsonmesmo diretório)

engine-strict=true

3
Essa é a solução mais fácil que fornece ao usuário final um bom e gordo erro por não ter a versão correta do nó quando é executado npm install; trabalha com yarnbem
jcollum

1
Isso parece não ter efeito algum. Eu configurei o meu package.jsoncom uma seção "mecanismos" semelhante à acima ( 11.13.0e 6.7.0), e uma .npmrccom nada além do conteúdo especificado acima. Eu tinha o nvm me mudar para uma versão mais antiga do nó e, em seguida, executei npm install, mas ele apenas instala as dependências e nem menciona a incompatibilidade de versão do mecanismo.
Adrian

54

Assim como disse o Ibam, engineStrictagora está obsoleto. Mas eu encontrei esta solução:

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"
  }
}

Saiba mais aqui: https://medium.com/@adambisek/how-to-check-minimum-required-node-js-version-4a78a8855a0f#.3oslqmig4

.nvmrc

E mais uma coisa. Um arquivo de ponto '.nvmrc' pode ser usado para exigir a versão específica do nó - https://github.com/creationix/nvm#nvmrc

Mas, isso é respeitado apenas pelos scripts npm (e scripts de fios).


2
Esta é a melhor resposta em 2019, à luz da depreciação do mecanismo de conjunto e da realidade de que muitos (provavelmente) estão enfrentando isso devido à alternância de versões com o nvm.
craft

14

.nvmrc

Se você estiver usando o NVM como este , o que provavelmente deveria, poderá indicar a versão do nodejs necessária para um determinado projeto em um .nvmrcarquivo rastreado pelo git :

echo v10.15.1 > .nvmrc

Isso não entra em vigor automaticamente cd, o que é sensato: o usuário deve fazer um:

nvm use

e agora essa versão do nó será usada para o shell atual.

Você pode listar as versões do nó que possui:

nvm list

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

Como selecionar automaticamente a versão do nó cdfoi solicitado em: Alternar automaticamente para a versão correta do nó com base no projeto

Testado com NVM 0.33.11.


8

Há outra maneira mais simples de fazer isso:

  1. npm install Node@8 (salva o nó 8 como dependência no package.json)
  2. Seu aplicativo será executado usando o Nó 8 para qualquer pessoa - até usuários do Yarn!

Isso funciona porque nodeé apenas um pacote que envia o nó como seu binário de pacote. Ele inclui apenas como node_module / .bin, o que significa que apenas disponibiliza o nó para os scripts do pacote. Não é o shell principal.

Veja a discussão no Twitter aqui: https://twitter.com/housecor/status/962347301456015360


5
Não concordo, isso poderia ocultar o problema e carregar de lado uma versão diferente do nó, caso não estivesse instalado.
Brendan Hannemann #

7
-1 porque é uma péssima (realmente péssima) ideia. É como dizer que, se você está desempregado, deve financiar uma empresa primeiro e pode começar a trabalhar lá.
Ozanmuyes

2
Parece uma ótima idéia para mim. Versões de nó separadas para projetos separados. Pode atualizar com segurança um sem atualizar os outros. O único problema é ter que executar .bin em ./node node-sassvez de apenas node-sass. Não tenho certeza se é o mesmo para todos os arquivos .bin.
Jon

2
Essa é uma solução simples e elegante - desde que os membros da equipe que trabalham no produto saibam que isso está acontecendo, acho que é uma ótima resposta. Estamos usando essa técnica em uma grande empresa para lidar com a variedade de versões do nó para uma dúzia de produtos front-end da web. Remove a necessidade de comutação constante com a nvm ao alternar entre produtos.
Nathan Bedford

2
Esta solução tem seus próprios prós e contras. O encapsulamento da versão do nó é potencialmente seu maior profissional. A desvantagem é o tamanho da imagem do Docker, se você deseja implantá-lo dessa maneira.
ivosh 2/10/19

0

Um exemplo de caso de teste 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
Não deve ser um teste de unidade, use package.json / dotfiles
bgcode

2
Mas whhhhhhhy, um teste de unidade é projetado para isso> .-
Jamie Nicholl-Shelley

Porque você precisa do Node para executar um teste de unidade. Se a versão do nó atual estiver muito desatualizada, os testes simplesmente não serão executados ou eles falharão com erro de sintaxe ou smth. similar, o que anula o ponto do teste de unidade. É como ocultar um formulário de redefinição de senha atrás de um formulário de autorização. Se você não se lembra da senha, precisa usar a função redefinir senha, mas agora não pode usá-la, porque não se lembra da senha.
ankhzet 15/06
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.