Dependências e pacotes

O código que você não escreveu

Um backend moderno usa bibliotecas para quase tudo: servidor HTTP, acesso ao banco, validação, datas, logs, clientes de outros serviços. Cada uma é uma dependência, e o gerenciador de pacotes cuida de baixá-las e de manter as versões certas.

Dependências diretas e indiretas

As dependências que você declara são as diretas. Cada uma tem as suas próprias dependências, que têm outras, e assim por diante. Essas são as indiretas, ou transitivas.

Medimos com um projeto Node vazio e uma única dependência, o framework Express na versão 4: 1 dependência direta trouxe 68 pacotes para a pasta node_modules.

seu projeto
└── express (direta)
    ├── body-parser
    │   ├── bytes
    │   ├── raw-body
    │   │   └── ...
    ├── cookie
    ├── send
    │   └── ...
    └── ... mais dezenas de pacotes

Cada um desses 68 pacotes foi escrito por alguém, roda com as mesmas permissões que o seu código e pode ter defeitos ou vulnerabilidades. Você escolheu um; confia em todos.

Versionamento semântico

A maioria dos ecossistemas segue o versionamento semântico (semver): um número no formato MAIOR.MENOR.CORREÇÃO, com uma promessa para cada parte.

O arquivo de dependências costuma declarar um intervalo de versões aceitas, e não uma versão exata:

O ^ é o padrão do npm install. A promessa do semver é uma intenção do autor do pacote, e não uma garantia: versões menores às vezes quebram coisas, por engano.

O arquivo de trava

Se o arquivo de dependências aceita um intervalo, o que é instalado depende do dia em que se instala. Testamos: um package.json pedindo express: ^4.17.0, instalado sem arquivo de trava, recebeu a versão 4.22.3, cinco versões menores depois da declarada. Outra pessoa, em outro dia, receberia outra.

O arquivo de trava (lockfile) registra a versão exata de cada pacote, direto e indireto, e um hash do conteúdo. Com ele, todas as instalações, na sua máquina, na do colega, no CI e na imagem de produção, recebem exatamente os mesmos pacotes.

Os comandos de instalação exata recusam um arquivo de trava que não bate com o arquivo de dependências. No teste, depois de acrescentar uma dependência no package.json sem atualizar a trava, o npm ci parou com erro, em vez de instalar algo diferente do registrado.

Integridade: o pacote é o mesmo?

O arquivo de trava também guarda um hash do conteúdo de cada pacote. Se o pacote baixado for diferente do registrado, por um registro comprometido ou um ataque no caminho, a instalação falha.

Testamos nos dois ecossistemas que tornam isso mais visível:

Os riscos da cadeia de suprimentos

As dependências são a cadeia de suprimentos do software. Os ataques a ela cresceram muito nos últimos anos, porque comprometer um pacote popular atinge milhares de sistemas de uma vez.

O segundo risco merece atenção. Criamos um pacote local com um script postinstall. Ao instalá-lo, o script executou na hora e gravou um arquivo com o diretório do usuário e as 40 variáveis de ambiente do processo, onde costumam estar tokens e senhas. Com --ignore-scripts, nada foi executado.

Por que isso importa quando a IA escreve o código

Assistentes sugerem dependências com naturalidade, e às vezes sugerem pacotes que não existem. Quem publica pacotes maliciosos já explora isso, registrando os nomes que os modelos costumam inventar. Outros problemas comuns:

• Uma dependência nova para algo que a biblioteca padrão já faz.
• Versões antigas, do período em que o modelo foi treinado, com vulnerabilidades já corrigidas.
• npm install no Dockerfile e no CI, em vez da instalação exata com o arquivo de trava.
• O arquivo de trava fora do repositório, ou apagado para "resolver" um conflito.
• Atualizações grandes, de várias versões maiores de uma vez, sem ler o que mudou.

O próximo nível compara as estratégias de versões, atualização e segurança.