O autor selecionou a Open Internet/Free Speech Fund para receber uma doação como parte do programa Write for DOnations.
Devido a funcionalidades como sua performance rápida de Input/Output (I/O), bem como sua sintaxe bastante conhecida em JavaScript, o Node.js se tornou rapidamente um ambiente de execução popular para o desenvolvimento Web de back-end. No entanto, à medida que o interesse cresce, aplicativos maiores são construídos e a complexidade da base de código e suas dependências torna-se mais difícil. O Node.js organiza esta complexidade usando módulos, que são todos os arquivos únicos do JavaScript que contêm funções ou objetos que podem ser usados por outros programas ou módulos. Uma coleção de um ou mais módulos é geralmente conhecida como um pacote e esses pacotes são organizados por gerenciadores de pacotes.
O Gerenciador de pacotes do Node.js (npm) é o gerenciador de pacotes padrão e o mais popular no ecossistema do Node.js, sendo usado principalmente para instalar e gerenciar módulos externos em um projeto do Node.js. Ele também é comumente usado para instalar uma ampla faixa de ferramentas CLI e executar scripts de projeto. O npm rastreia os módulos instalados em um projeto com o arquivo package.json
, que reside em um diretório de projeto e contém:
Conforme cria projetos mais complexos do Node.js, gerenciar seus metadados e dependências com o arquivo package.json
dará a você compilações mais previsíveis, uma vez que todas as dependências externas são mantidas as mesmas. O arquivo acompanhará essas informações automaticamente; embora possa alterar o arquivo diretamente para atualizar os metadados do seu projeto, você raramente precisará interagir com ele diretamente para gerenciar os módulos.
Neste tutorial, você gerenciará pacotes com o npm. O primeiro passo será criar e entender o arquivo package.json
. Então, você o utilizará para acompanhar todos os módulos que instalar em seu projeto. Por fim, listará as dependências do seu pacote, atualizará seus pacotes, desinstalará os pacotes e executará uma auditoria para encontrar falhas de segurança neles.
Para completar este tutorial, você precisará de:
package.json
Começamos este tutorial configurando o projeto exemplo — um módulo fictício locator
do Node.js que recebe o endereço IP do usuário e retorna o país de origem. Você não vai codificar o módulo neste tutorial. No entanto, os pacotes que você gerencia seriam relevantes caso estivesse os desenvolvendo.
Primeiro, será criado um arquivo package.json
para armazenar metadados úteis sobre o projeto e ajudar você a gerenciar os módulos Node.js dependentes do projeto. Como o sufixo sugere, este é um arquivo JSON (Notação de objetos JavaScript). O JSON é um formato padrão usado para compartilhamento, com base nos objetos do JavaScript e constituído por dados armazenados como pares de chave-valor. Caso queira aprender mais sobre o JSON, leia nosso artigo Introdução ao JSON.
Como um arquivo package.json
contém várias propriedades, pode ser complicado criá-lo manualmente, sem copiar e colar um modelo de outro lugar. Para facilitar as coisas, o npm fornece o comando init
. Este é um comando interativo que faz uma série de perguntas e cria um arquivo package.json
com base em suas respostas.
init
Primeiro, monte um projeto para que você possa praticar o gerenciamento de módulos. No seu shell, crie uma nova pasta chamada locator
:
- mkdir locator
Então, vá até o novo diretório:
- cd locator
Agora, inicialize o prompt interativo digitando:
- npm init
Nota: se seu código for usar o Git para o controle de versão, crie o repositório Git primeiro para, em seguida, executar npm init
. O comando compreende automaticamente que está em uma pasta habilitada para o Git. Caso um Git remoto esteja definido, ele preenche automaticamente os campos do repository
, bugs
e homepage
para o seu arquivo package.json
. Caso tenha inicializado o repositório após criar o arquivo package.json
, será necessário adicionar essas informações você mesmo. Para obter mais informações sobre o controle de versão do Git, consulte nossa série Introdução ao Git: instalação, uso e ramificações.
Você receberá o seguinte resultado:
OutputThis utility will walk you through creating a package.json file.
It only covers the most common items, and tries to guess sensible defaults.
See `npm help json` for definitive documentation on these fields
and exactly what they do.
Use `npm install <pkg>` afterwards to install a package and
save it as a dependency in the package.json file.
Press ^C at any time to quit.
package name: (locator)
Primeiro, será solicitado o name
(nome) do seu novo projeto. Por padrão, o comando supõe que este seja o nome da pasta em que você está. Os valores padrão para cada propriedade são mostrados entre parênteses ()
. Como o valor padrão para o name
irá funcionar para este tutorial, pressione ENTER
para aceitá-lo.
O próximo valor a ser adicionado é version
(versão). Junto com o name
, este campo é necessário caso seu projeto seja compartilhado com outros no repositório de pacotes do npm.
Nota: espera-se que os pacotes do Node.js sigam o guia Versionamento semântico (semver). Portanto, o primeiro número será o número de versão MAJOR
, que muda somente quando a API muda. O segundo número será da versão do MINOR
, que muda quando funcionalidades são adicionadas. O último número será da versão do PATCH
, que muda quando bugs são consertados.
Pressione ENTER
para que a versão padrão seja aceita.
O próximo campo é description
(descrição) — uma string útil para explicar o que o seu módulo Node.js faz. Nosso projeto fictício locator
recebe o endereço IP do usuário para retornar o país de origem. Uma description
adequada seria Finds the country of origin of the incoming request
(Encontra o país de origem da solicitação de entrada), então digite algo nesse sentido e pressione ENTER
. A description
é muito útil quando as pessoas estiverem à procura do seu módulo.
O prompt a seguir irá solicitar o entry point
(ponto de entrada). Caso alguém instale e exija seu módulo pelo comando requires
, o que você definiu no entry point
será a primeira parte do seu programa a ser carregada. O valor precisa ser o local relativo de um arquivo JavaScript e será adicionado à propriedade main
do package.json
. Pressione ENTER
para manter o valor padrão.
Nota: a maioria dos módulos tem um arquivo index.js
como o ponto de entrada principal. Este é o valor padrão para a propriedade main
do package.json
, que é o ponto de entrada para os módulos do npm. Caso não haja um package.json
, o Node.js tentará carregar o index.js
por padrão.
Em seguida, será solicitado a um test command
(comando teste) a você, um script executável ou comando para executar seus testes de projeto. Em muitos módulos populares do Node.js, os testes são escritos e executados com o Mocha, Jest, Jasmine, ou outros frameworks de teste. Como os testes estão além do âmbito deste artigo, deixe esta opção vazia por enquanto e pressione ENTER
para continuar.
Então, o comando init
irá pedir pelo repositório do GitHub do projeto. Você não usará isso neste exemplo, então deixe-o vazio também.
Após o prompt do repositório, o comando solicita keywords
(palavras-chave). Essa propriedade é uma matriz de strings com termos úteis que as pessoas podem usar para encontrar seu repositório. É melhor ter um pequeno conjunto de palavras que são realmente relevantes para o seu projeto, de forma que a busca seja mais direcionada. Liste essas palavras-chave como uma string com vírgulas separando cada valor. Para este projeto de amostra, digite ip,geo,country
no prompt. O package.json
finalizado terá três itens na matriz para keywords
.
O próximo campo no prompt é o author
(autor). Ele é útil para os usuários do seu módulo que querem entrar em contato com você. Por exemplo, caso alguém descubra uma falha em seu módulo, essa pessoa pode usar isso para informar o problema, para que você possa corrigi-lo. O campo de author
é uma string no seguinte formato: "Name \<Email\> (Website)"
Por exemplo, "Sammy \<sammy@your_domain\> (https://your_domain)"
é um autor válido. Os dados de e-mail e do site são opcionais — um autor válido poderia ser apenas um nome. Adicione seus detalhes de contato como autor e confirme com ENTER
.
Por fim, você será solicitado a colocar a license
(licença). Isso determina as permissões e limitações legais que os usuários terão ao usar seu módulo. Muitos módulos do Node.js são de código aberto, então o npm define o padrão para ISC.
Neste ponto, você deveria revisar suas opções de licenciamento e decidir o que é melhor para o seu projeto. Para obter mais informações sobre diferentes tipos de licenças de código aberto, consulte esta lista de licenças da Iniciativa Open Source. Caso não queira fornecer uma licença para um repositório privado, você pode digitar UNLICENSED
no prompt. Para essa amostra, utilize a licença padrão ISC e pressione ENTER
para finalizar esse processo.
O comando init
exibirá agora o arquivo package.json
que ele criará. Ele ficará parecido com este:
OutputAbout to write to /home/sammy/locator/package.json:
{
"name": "locator",
"version": "1.0.0",
"description": "Finds the country of origin of the incoming request",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"keywords": [
"ip",
"geo",
"country"
],
"author": "Sammy <sammy@your_domain> (https://your_domain)",
"license": "ISC"
}
Is this OK? (yes)
Assim que as informações forem correspondentes ao que vê aqui, pressione ENTER
para completar este processo e criar o arquivo package.json
. Com este arquivo, você pode manter um registro dos módulos que instala para o seu projeto.
Agora que tem seu arquivo package.json
, você pode testar a instalação de módulos no próximo passo.
É comum no desenvolvimento de software utilizar bibliotecas externas para realizar tarefas auxiliares em projetos. Isso permite que o desenvolvedor se concentre na lógica de negócios e crie o aplicativo com maior rapidez e eficiência.
Por exemplo, caso nosso módulo de amostra locator
tenha que fazer uma solicitação de API externa para obter dados geográficos, poderíamos utilizar uma biblioteca HTTP para facilitar essa tarefa. Como nosso objetivo principal é retornar dados geográficos pertinentes para o usuário, poderíamos instalar um pacote que torna as solicitações HTTP mais fáceis para nós, ao invés de reescrever esse código por conta própria. O que seria uma tarefa que está além do âmbito do nosso projeto.
Vamos testar este exemplo. No seu aplicativo locator
, você utilizará a biblioteca axios, que ajudará você a fazer solicitações HTTP. Instale-a digitando o seguinte em seu shell:
- npm install axios --save
Você inicia este comando com o npm install
, que instalará o pacote (para ser conciso, pode utilizar o npm i
). Então, liste os pacotes que deseja que sejam instalados, separados por um espaço. Neste caso, trata-se do axios
. Por fim, você termina o comando com o parâmetro opcional --save
, que especifica que o axios
será salvo como uma dependência do projeto.
Quando a biblioteca for instalada, você verá um resultado similar ao seguinte:
Output...
+ axios@0.19.0
added 5 packages from 8 contributors and audited 5 packages in 0.764s
found 0 vulnerabilities
Agora, abra o arquivo package.json
, usando um editor de texto de sua escolha. Este tutorial usará o nano
.
- nano package.json
Você verá uma nova propriedade, assim como destacado a seguir:
{
"name": "locator",
"version": "1.0.0",
"description": "Finds the country of origin of the incoming request",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"keywords": [
"ip",
"geo",
"country"
],
"author": "Sammy sammy@your_domain (https://your_domain)",
"license": "ISC",
"dependencies": {
"axios": "^0.19.0"
}
}
A opção --save
disse ao npm para atualizar o package.json
com o módulo e versão que acabou de ser instalada. Isso é ótimo, já que outros desenvolvedores trabalhando em seus projetos podem ver facilmente quais dependências externas são necessárias.
Nota: você deve ter notado o ^
antes do número de versão para a dependência do axios
. Lembre-se que o versionamento semântico consiste em três dígitos: MAJOR, MINOR e PATCH. O símbolo de ^
significa que qualquer versão superior do MINOR ou do PATCH atenderia a essa restrição de versão. Caso veja ~
no início de um número de versão, então apenas versões superiores do PATCH satisfazem a restrição.
Quando terminar de revisar o package.json
, saia do arquivo.
Os pacotes que são usados para o desenvolvimento de um projeto, mas não para sua compilação ou execução na produção são chamados de dependências de desenvolvimento. Eles não são necessários para que seu módulo ou aplicativo funcione em produção, mas podem ser úteis ao escrever o código.
Por exemplo, é comum que os desenvolvedores usem linters de código para garantir que seu código segue as melhores práticas e manter o estilo consistente. Embora seja útil para o desenvolvimento, isso apenas aumenta o tamanho do distribuível sem fornecer um benefício concreto quando implantado na produção.
Instale um linter como uma dependência de desenvolvimento para seu projeto. Experimente isto em seu shell:
- npm i eslint@6.0.0 --save-dev
Neste comando, você usou o sinalizador --save-dev
. Isso salvará o eslint
como uma dependência que é necessária apenas para o desenvolvimento. Note também que você adicionou @6.0.0
ao nome da sua dependência. Quando os módulos são atualizados, eles são marcados com uma versão. O @
diz ao npm para procurar um sinalizador específico do módulo que você está instalando. Sem um sinalizador especificado, o npm instala a versão marcada mais recente. Abra o package.json
novamente:
- nano package.json
Isso mostrará o seguinte:
{
"name": "locator",
"version": "1.0.0",
"description": "Finds the country of origin of the incoming request",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"keywords": [
"ip",
"geo",
"country"
],
"author": "Sammy sammy@your_domain (https://your_domain)",
"license": "ISC",
"dependencies": {
"axios": "^0.19.0"
},
"devDependencies": {
"eslint": "^6.0.0"
}
}
O eslint
foi salvo como uma devDependencies
, junto com o número da versão que você especificou mais cedo. Saia do package.json
.
node_modules
e package-lock.json
Quando você instala um pacote em um projeto do Node.js pela primeira vez, o npm cria automaticamente a pasta node_modules
. Ela é usada para armazenar os módulos necessários para o seu projeto e o arquivo package-lock.json
que você examinou mais cedo.
Confirme que eles estão em seu diretório de trabalho. Em seu shell, digite ls
e pressione ENTER
. Você observará o seguinte resultado:
Outputnode_modules package.json package-lock.json
A pasta node_modules
contém todas as dependências instaladas para o seu projeto. Na maioria dos casos, você não deve enviar essa pasta em seu repositório controlado por versão. Conforme instala mais dependências, o tamanho dessa pasta crescerá rapidamente. Além disso, o arquivo package-lock.json
mantém um registro das versões exatas instaladas de uma maneira mais sucinta. Assim, incluir o node_modules
não é necessário.
Enquanto o arquivo package.json
lista as dependências que nos informam as versões adequadas que devem ser instaladas para o projeto, o arquivo package-lock.json
acompanha todas as alterações no package.json
ou node_modules
e nos informa a versão exata do pacote instalado. Normalmente, você envia isso para seu repositório controlado por versão, ao invés do node_modules
, pois é uma representação mais clara de todas as suas dependências.
Usando seus arquivos package.json
e package-lock.json
, você consegue configurar rapidamente as mesmas dependências de projeto antes de iniciar o desenvolvimento de um novo projeto. Para demonstrar isso, suba um nível em sua árvore de diretórios e crie uma nova pasta chamada cloned_locator
no mesmo nível de diretório que o locator
:
- cd ..
- mkdir cloned_locator
Vá para seu novo diretório:
- cd cloned_locator
Agora, copie os arquivos package.json
e package-lock.json
da pasta locator
para cloned_locator
:
- cp ../locator/package.json ../locator/package-lock.json .
Para instalar os módulos necessários para este projeto, digite:
- npm i
O npm verificará se há um arquivo package-lock.json
para instalar os módulos. Caso nenhum arquivo lock esteja disponível, ele leria a partir do arquivo package.json
para determinar as instalações. Normalmente, é mais rápido instalar a partir do package-lock.json
, pois o arquivo lock contém a versão exata dos módulos e suas dependências. Isso significa que o npm não precisa gastar tempo para descobrir uma versão adequada para instalar.
Ao implantar para a produção, pode ser que queira ignorar as dependências de desenvolvimento. Lembre-se que as dependências de desenvolvimento são armazenadas na seção devDependencies
do package.json
e não têm impacto na execução do seu aplicativo. Ao instalar módulos como parte do processo CI/CD para implantar o seu aplicativo, omita as dependências de desenvolvimento, executando:
- npm i --production
O sinalizador --production
ignora a seção devDependencies
durante a instalação. Por enquanto, permaneça com sua compilação de desenvolvimento.
Antes de ir para a seção seguinte, volte para a pasta locator
:
- cd ../locator
Até agora, você esteve instalando os módulos npm para o projeto locator
. O npm também permite que você instale pacotes globalmente. Isso significa que o pacote está disponível para seu usuário no sistema como um todo, assim como qualquer outro comando do shell . Essa habilidade é útil para os muitos módulos do Node.js que são ferramentas CLI.
Por exemplo, pode ser que queira fazer postagens em blog sobre o projeto locator
no qual você está trabalhando atualmente. Para fazer isso, utilize uma biblioteca como o Hexo para criar e gerenciar seu site de blog estático. Instale o Hexo CLI globalmente, desta forma:
- npm i hexo-cli -g
Para instalar um pacote globalmente, você adiciona o sinalizador -g
ao comando.
Nota: se receber um erro de permissão ao tentar instalar este pacote globalmente, seu sistema pode exigir privilégios de super-usuário para executar o comando. Tente novamente com sudo npm i hexo-cli -g
.
Teste se o pacote foi instalado com sucesso, digitando:
- hexo --version
Você verá um resultado semelhante a:
Outputhexo-cli: 2.0.0
os: Linux 4.15.0-64-generic linux x64
http_parser: 2.7.1
node: 10.14.0
v8: 7.6.303.29-node.16
uv: 1.31.0
zlib: 1.2.11
ares: 1.15.0
modules: 72
nghttp2: 1.39.2
openssl: 1.1.1c
brotli: 1.0.7
napi: 4
llhttp: 1.1.4
icu: 64.2
unicode: 12.1
cldr: 35.1
tz: 2019a
Até agora, você aprendeu como instalar os módulos com o npm. É possível instalar os pacotes em um projeto localmente, seja como uma dependência de produção ou de desenvolvimento. Você também pode instalar pacotes com base nos arquivos package.json
ou package-lock.json
pré-existentes, permitindo que desenvolva com as mesmas dependências que seus pares. Por fim, você pode utilizar o sinalizador -g
para instalar os pacotes globalmente. Assim, você pode acessá-los independentemente se estiver em um projeto Node.js, ou não.
Agora que você é capaz de instalar os módulos, na seção seguinte, você praticará técnicas para administrar suas dependências.
Um gerenciador de pacotes completo pode fazer muito mais do que instalar módulos. O npm possui mais de 20 comandos relacionados ao gerenciamento de dependências disponível. Neste passo, você irá:
Embora esses exemplos sejam feitos em sua pasta locator
, todos esses comandos podem ser executados globalmente, adicionando o sinalizador -g
no final deles, exatamente como você fez quando instalou globalmente.
Caso queira saber quais módulos estão instalados em um projeto, é mais fácil usar uma list
(lista), ou ls
, ao invés de ler o package.json
diretamente. Para fazer isso, digite:
- npm ls
Você verá um resultado como este:
Output├─┬ axios@0.19.0
│ ├─┬ follow-redirects@1.5.10
│ │ └─┬ debug@3.1.0
│ │ └── ms@2.0.0
│ └── is-buffer@2.0.3
└─┬ eslint@6.0.0
├─┬ @babel/code-frame@7.5.5
│ └─┬ @babel/highlight@7.5.0
│ ├── chalk@2.4.2 deduped
│ ├── esutils@2.0.3 deduped
│ └── js-tokens@4.0.0
├─┬ ajv@6.10.2
│ ├── fast-deep-equal@2.0.1
│ ├── fast-json-stable-stringify@2.0.0
│ ├── json-schema-traverse@0.4.1
│ └─┬ uri-js@4.2.2
...
Por padrão, o ls
mostra toda a árvore de dependências — os módulos dos quais seu projeto depende e os módulos dos quais suas dependências dependem. Isso pode ser um pouco complicado caso queira um panorama de alto nível sobre o que está instalado.
Para imprimir apenas os módulos que você instalou, sem as suas dependências, digite o seguinte em seu shell:
- npm ls --depth 0
O resultado será:
Output├── axios@0.19.0
└── eslint@6.0.0
A opção --depth
permite que você especifique qual nível da árvore de dependências quer usar. Quando ele é 0
, você verá apenas suas dependências de nível superior.
É uma boa prática manter seus módulos do npm atualizados. Isso melhora sua probabilidade de obter os ajustes de segurança mais recentes para um módulo. Use o comando outdated
para verificar se algum módulo pode ser atualizado:
- npm outdated
Você receberá um resultado como o seguinte:
OutputPackage Current Wanted Latest Location
eslint 6.0.0 6.7.1 6.7.1 locator
Este comando lista primeiro o Package
(pacote) que está instalado e a versão Current
(atual). A coluna WANTED
mostra qual versão satisfaz sua exigência de versão no package.json
. A coluna Latest
mostra a versão mais recente publicada do módulo.
A coluna Location
declara onde o pacote está localizado na árvore de dependências. O comando outdated
tem o sinalizador --depth
, assim como ls
. Por padrão, o depth é 0.
Parece que você pode atualizar o eslint
para uma versão mais recente. Use o comando update
ou up
, desta forma:
- npm up eslint
O resultado do comando incluirá a versão instalada:
Outputnpm WARN locator@1.0.0 No repository field.
+ eslint@6.7.1
added 7 packages from 3 contributors, removed 5 packages, updated 19 packages, moved 1 package and audited 184 packages in 5.818s
found 0 vulnerabilities
Caso quisesse atualizar todos os módulos de uma só vez, digitaria:
- npm up
O comando npm uninstall
é capaz de remover módulos dos seus projetos. Isso significa que o módulo já não estará mais instalado na pasta node_modules
. Além disso, ele também não será visto em seus arquivos package.json
e package-lock.json
.
Remover dependências de um projeto é uma atividade normal no ciclo de desenvolvimento de software. Uma dependência pode não resolver o problema como anunciado, ou não fornecer uma experiência de desenvolvimento satisfatória. Nestes casos, é melhor desinstalar a dependência e compilar seu próprio módulo.
Imagine que o axios
não forneça a experiência de desenvolvimento que você gostaria de ter ao fazer solicitações HTTP. Desinstale o axios
com o comando uninstall
ou un
, digitando:
- npm un axios
Seu resultado será parecido com este:
Outputnpm WARN locator@1.0.0 No repository field.
removed 5 packages and audited 176 packages in 1.488s
found 0 vulnerabilities
Ele não diz explicitamente que o axios
foi removido. Para verificar se ele foi desinstalado, liste as dependências novamente:
- npm ls --depth 0
Agora, vemos que apenas o eslint
está instalado:
Output└── eslint@6.7.1
Isso mostra que você desinstalou o pacote axios
com sucesso.
O npm fornece um comando audit
(auditoria) para destacar possíveis riscos de segurança em suas dependências. Para ver a auditoria em ação, instale uma versão desatualizada do módulo de solicitação, executando o seguinte:
- npm i request@2.60.0
Ao instalar essa versão desatualizada de request
(solicitação), você notará um resultado semelhante ao seguinte:
Output+ request@2.60.0
added 54 packages from 49 contributors and audited 243 packages in 7.26s
found 6 moderate severity vulnerabilities
run `npm audit fix` to fix them, or `npm audit` for details
O npm está dizendo que você tem vulnerabilidades em suas dependências. Para obter mais detalhes, faça a auditoria em todo o seu projeto com:
- npm audit
O comando audit
mostra tabelas resultantes destacando falhas de segurança:
Output === npm audit security report ===
# Run npm install request@2.88.0 to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate │ Memory Exposure │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ tunnel-agent │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ request │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ request > tunnel-agent │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://npmjs.com/advisories/598 │
└───────────────┴──────────────────────────────────────────────────────────────┘
# Run npm update request --depth 1 to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate │ Remote Memory Exposure │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ request │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ request │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ request │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://npmjs.com/advisories/309 │
└───────────────┴──────────────────────────────────────────────────────────────┘
...
É possível ver o caminho da vulnerabilidade e, às vezes, o npm oferece maneiras para corrigi-la. Você pode executar o comando de atualização como sugerido, ou executar o subcomando fix
do audit
. Em seu shell, digite:
- npm audit fix
Você verá um resultado semelhante a:
Output+ request@2.88.0
added 19 packages from 24 contributors, removed 32 packages and updated 12 packages in 6.223s
fixed 2 of 6 vulnerabilities in 243 scanned packages
4 vulnerabilities required manual review and could not be updated
O npm conseguiu atualizar com segurança dois dos pacotes, diminuindo suas vulnerabilidades na mesma medida. No entanto, você ainda tem quatro vulnerabilidades em suas dependências. O comando audit fix
nem sempre conserta todos os problemas. Uma versão de um módulo pode ter uma vulnerabilidade de segurança. Entretanto, caso você atualize ela para uma versão com uma API diferente, isso poderia causar uma quebra do código mais elevado na árvore de dependências.
Você pode utilizar o parâmetro --force
para garantir que as vulnerabilidades se foram, desta forma:
- npm audit fix --force
Como mencionado anteriormente, isso não é recomendado, a menos que tenha certeza de que ela não quebrará a funcionalidade do código.
Neste tutorial, você passou por vários exercícios para demonstrar que os módulos do Node.js são organizados em pacotes, e como esses pacotes são gerenciados pelo npm. Em um projeto do Node.js, você usou pacotes do npm como dependências. Fez isso através da criação e manutenção de um arquivo package.json
— um registro dos metadados do seu projeto, incluindo quais módulos foram instalados. Você também usou a ferramenta CLI do npm para instalar, atualizar e remover módulos. Além disso, listou a árvore de dependências dos seus projetos e verificou e atualizou módulos desatualizados.
No futuro, potencializar o código existente, usando módulos, irá acelerar o tempo de desenvolvimento, pois faz com que não precise repetir a funcionalidade. Você também conseguirá criar seus próprios módulos do npm. Estes serão gerenciados por outros via comandos do npm. Caso deseje continuar, faça um teste com o que você aprendeu neste tutorial, instalando e testando a grande variedade dos pacotes existentes. Veja o que o ecossistema proporciona para facilitar a solução do problemas. Por exemplo, você poderia testar o TypeScript, um superconjunto do JavaScript, ou transformar seu site em aplicativos móveis com o Cordova. Caso queira aprender mais sobre o Node.js, consulte nossos outros tutoriais do Node.js.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!