Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Se você estiver desenvolvendo um aplicativo Node.js com muitos pacotes npm, não é incomum encontrar avisos ou erros ao criar seu projeto se um ou mais pacotes tiverem sido atualizados. Às vezes, um conflito de versão resulta ou uma versão do pacote foi preterida. Aqui estão algumas dicas rápidas para ajudá-lo a configurar seu arquivo package.json e entender o que está acontecendo quando você vê avisos ou erros. Este não é um guia completo para package.json e é focado apenas no versionamento de pacotes npm.
O sistema de versionamento de pacotes npm tem regras rígidas. O formato da versão segue aqui:
[major].[minor].[patch]
Digamos que você tenha um pacote em seu aplicativo com uma versão da 5.2.1. A versão principal é 5, a versão secundária é 2 e o patch é 1.
- Em uma atualização de versão principal, o pacote inclui novos recursos que são incompatíveis com versões anteriores, ou seja, alterações disruptivas.
- Numa atualização de versão menor, novos recursos foram adicionados ao pacote que são retrocompatíveis com versões anteriores do pacote.
- Em uma atualização de patch, uma ou mais correções de bugs são incluídas. As correções de bugs são sempre compatíveis com versões anteriores.
Vale a pena notar que alguns recursos do pacote npm têm dependências. Por exemplo, para usar um novo recurso do pacote de compilador TypeScript (ts-loader) com webpack, é possível que você também precise atualizar o pacote npm do webpack e o pacote webpack-cli.
Para ajudar a gerenciar o controle de versão do pacote, o npm suporta várias notações que você pode usar no package.json. Você pode usar essas notações para controlar o tipo de atualizações de pacote que deseja aceitar em seu aplicativo.
Digamos que você esteja usando o React e precise incluir o pacote react e react-dom npm. Você pode especificar isso de várias maneiras em seu arquivo package.json . Por exemplo, você pode especificar o uso da versão exata de um pacote da seguinte maneira.
"dependencies": {
"react": "16.4.2",
"react-dom": "16.4.2",
},
Usando a notação anterior, o npm sempre obterá a versão exata especificada, 16.4.2.
Você pode usar uma notação especial para limitar as atualizações a atualizações de patch (correções de bugs). Neste exemplo:
"dependencies": {
"react": "~16.4.2",
"react-dom": "~16.4.2",
},
Você usa o caractere til (~) para dizer ao NPM para atualizar um pacote apenas quando ele for corrigido. Assim, o npm pode atualizar o react 16.4.2 para 16.4.3 (ou 16.4.4, etc.), mas não aceitará uma atualização para a versão principal ou secundária. Assim, 16.4.2 não será atualizado para 16.5.0.
Você também pode usar o acento circunflexo (^) para especificar que o npm pode atualizar a versão menor.
"dependencies": {
"react": "^16.4.2",
"react-dom": "^16.4.2",
},
Usando essa notação, o npm pode atualizar o react 16.4.2 para 16.5.0 (ou 16.5.1, 16.6.0, etc.), mas não aceitará uma atualização para a versão principal. Assim, 16.4.2 não será atualizado para 17.0.0.
Quando o npm atualiza pacotes, ele gera um arquivo package-lock.json , que lista as versões reais do pacote npm usadas em seu aplicativo, incluindo todos os pacotes aninhados. Embora package.json controle as dependências diretas do seu aplicativo, ele não controla as dependências aninhadas (outros pacotes npm exigidos por um pacote npm específico). Você pode usar o arquivo package-lock.json em seu ciclo de desenvolvimento se precisar ter certeza de que outros desenvolvedores e testadores estão usando os pacotes exatos que você está usando, incluindo pacotes aninhados. Para obter mais informações, consulte package-lock.json na documentação do npm.
Para o Visual Studio, o arquivo package-lock.json não é adicionado ao seu projeto, mas você pode encontrá-lo na pasta do projeto.