Testes mais rápidos e aprimorados para projetos JavaScript baseados em arquivos de lock

Nos últimos meses, trabalhamos intensamente para aprimorar o suporte a arquivos de lock, tanto na CLI quanto na integração com SCM. A nova funcionalidade já está disponível na CLI e está sendo liberada gradualmente na web. Em breve, ela será ativada por padrão para todas as organizações.

Muitos projetos Node.js dependem de yarn.lock ou package-lock.json para ajudar os desenvolvedores a repetir instalações e sincronizar ambientes, melhorando a experiência de desenvolvimento colaborativo.

Não há dúvida de que os arquivos de lock são extremamente úteis — seu uso cresceu muito. Temos trabalhado para aprimorar o suporte a esses arquivos para todos os usuários, oferecendo resultados de teste ainda mais precisos e um desempenho muito mais rápido.

Por que precisávamos melhorar o suporte a arquivos de lock na CLI?

Até pouco tempo, percorríamosnode_modules para identificar todas as dependências instaladas no disco. Esse processo se mostrou bastante lento e, às vezes, impreciso, poisnode_modules muitas vezes continha dependências removidas há muito tempo e que já não eram usadas pelo projeto. Embora todos tentemos manter tudo atualizado, nem sempre é viável excluir a pasta node_modules e fazer uma instalação do zero para garantir que apenas os pacotes usados no projeto estejam presentes.

Sonhávamos com um mundo em que você não precisasse instalar os pacotes para executarmos um teste. Após algum planejamento, criamos uma nova bibliotecanode-lockfile-parser, capaz de percorrer o próprio arquivo de lock e o arquivo package.json, em vez de toda a pastanode_modules. Com isso, hoje contamos com um desempenho e uma precisão muito melhores.

Se houver um arquivoyarn.lock oupackage-json.lock no projeto, vamos detectá-lo automaticamente e processar o projeto com base no arquivo de lock. Para projetos sem arquivos de lock, o suporte continua igual ao de antes.

Observação:

• snyk patch ewizard ainda exigirão que a pastanode_modules esteja presente, pois precisamos aplicar os patches diretamente nas pastas dos pacotes instalados.

• Projetos Yarn em versões do Node anteriores à 6 também continuarão percorrendonode_module. Isso ocorre porque uma biblioteca do Yarn, usada para analisar o arquivo de lock, não oferece suporte a versões do Node anteriores à 6.

Como isso afeta meus projetos na web?

Ao importar um projeto pelo GitHub, GitLab ou Bitbucket, antes usávamos apenas o arquivopackage.json para determinar as dependências do projeto. Isso significava que precisávamos presumir a versão exata de cada pacote instalado no disco e sempre presumíamos a melhor opção (ou seja, a versão mais recente de cada pacote compatível com o intervalo semver definido no arquivopackage.json).

Com a adição do suporte a arquivos de lock, agora podemos oferecer resultados de teste mais precisos. Hoje, um teste do Snyk cria uma árvore com base nas versões exatas resolvidas de cada pacote no arquivo de lock. Isso significa que, no próximo teste do Snyk, podemos identificar vulnerabilidades que não haviam sido relatadas anteriormente. Mas não se preocupe: se a configuração de autofix de PR/MR estiver ativada, essas vulnerabilidades serão corrigidas como de costume, e você receberá notificações com outras formas de lidar com elas.

O Snyk vai gerar novamente os arquivos de lock do meu projeto?

Ainda não. Estamos trabalhando intensamente para oferecer essa funcionalidade para projetos Yarn e npm. Essa tarefa não é simples, devido às grandes diferenças na lógica interna de resolução de pacotes do Yarn e do npm, além das diferenças entre seus arquivos de lock.

Até lá, todas as pull requests ainda precisarão de intervenção manual, como acontece hoje. Portanto, se o arquivo yarn.lock ou package-lock.json do projeto tiver sido alterado, será necessário atualizar o arquivo de lock antes de mesclar a pull request se o arquivo package.json tiver mudado.