npm v12 anuncia mudanças que quebram compatibilidade

 (github.blog)
1 pontos por GN⁺ 2026-06-11 | 1 comentários | Compartilhar no WhatsApp
  • O comportamento padrão de npm install vai mudar para um modelo focado em segurança, em que recursos antes executados automaticamente passarão a funcionar apenas com permissão explícita do usuário (opt-in)
  • allowScripts desativado por padrão — scripts preinstall, install e postinstall presentes em pacotes externos instalados serão bloqueados por padrão, e só serão executados para pacotes permitidos pelo projeto
    • A mudança bloqueia scripts que antes rodavam automaticamente só por instalar um pacote, reduzindo a chance de código malicioso se infiltrar
    • Builds nativos com node-gyp também entram no bloqueio, então até pacotes que só têm binding.gyp e nenhum script de instalação separado deixarão de ser compilados (porque o npm executa internamente node-gyp rebuild)
    • O script prepare de pacotes obtidos via git, file ou link também será bloqueado da mesma forma
    • Uso: verifique quais pacotes têm scripts com npm approve-scripts --allow-scripts-pending → permita apenas os confiáveis com npm approve-scripts e bloqueie o restante com npm deny-scripts → como a lista de permissões é salva no package.json, faça commit dela
  • --allow-git com valor padrão none — pacotes obtidos diretamente de repositórios Git (incluindo os que eles próprios puxam) serão bloqueados por padrão, e a instalação só acontecerá se forem permitidos com --allow-git
    • Isso bloqueia o caminho pelo qual o .npmrc dentro de um pacote Git podia substituir o próprio executável do Git (--ignore-scripts também não impedia esse problema) (npm 11.10.0+)
  • --allow-remote com valor padrão none — pacotes obtidos por URL remota, como tarballs via https (incluindo dependências transitivas), serão bloqueados por padrão, e só poderão ser instalados se forem permitidos com --allow-remote (npm 11.15.0+)
    • Já --allow-file e --allow-directory não terão seus valores padrão alterados nesta v12
  • Todas essas mudanças serão oferecidas primeiro como avisos no npm 11.16.0 ou superior, permitindo verificar e se preparar antes do lançamento oficial
  • A previsão de lançamento da v12 é julho de 2026

Leituras relacionadas

1 comentários

 
GN⁺ 2026-06-11
Comentários do Hacker News

  • Não sei como deixei passar que o npm foi adquirido pelo GitHub, mas de repente muita coisa começou a fazer sentido
    É difícil pensar em um lugar pior para abrigar uma parte tão importante do ecossistema Node

  • Scripts de postinstall já deveriam ter sido removidos há muito tempo e são um câncer nos pacotes NPM
    Tem postinstalls profundamente aninhados e sem controle demais sendo executados aleatoriamente quando você baixa alguma coisa
    Não sei quem em algum momento achou que isso era uma boa ideia

    • Não acho que entendo muito bem a essência da preocupação com scripts de post-install
      Normalmente você vai acabar executando o código de dependência empacotado de qualquer forma em algum momento, e em geral com os mesmos privilégios do processo de instalação
      Então esses scripts de configuração, sejam bons ou ruins, podem simplesmente mover seu ponto de entrada do npm para onde acontece o import ou require
      A menos que todo o ecossistema migre para um ambiente sandboxed como o Deno, isso parece no máximo um pequeno obstáculo. Embora esse possa ser o plano
    • Isso absolutamente não deveria acontecer, e há muitos casos de uso válidos
      Um exemplo que me vem à cabeça imediatamente é https://www.npmjs.com/package/patch-package
      Espero que a histeria atual não leve a decisões inúteis desse tipo

  • Isso provavelmente foi discutido centenas de vezes dentro do NPM desde que veio a público 10 anos atrás
    Por causa de Shai Halud, agora ficou grande demais para ignorar

    • Gosto de como a história do JavaScript basicamente parece uma destilação de um modo de pensar de desenvolvedor
      “A gente corrige depois” quase sempre vira “droga, agora a gente tem que corrigir”
    • Ótimo, agora é a vez do Python

  • Fico curioso se as versões LTS atuais do Node, se bem me lembro 22, 24, 26, vão atualizar o npm empacotado para o v12 para receber esse ajuste de segurança
    No momento todas incluem o npm v11

    • Já houve upgrade de versão major do npm em releases intermediárias do Node no passado
      O npm foi de 9 para 10 no v18.19.0[1] e no v20.10.0[2]
      [1]: https://nodejs.org/en/blog/release/v18.19.0#npm-updated-to-v...
      [2]: https://nodejs.org/en/blog/release/v20.10.0
    • Como é uma mudança de padrão, dá para ver como uma mudança de postura de segurança, mas o ajuste de segurança em si todos já podem aplicar
      Como o texto diz, basta configurar os padrões adequados
      A melhor parte dessa mudança é que, com o padrão alterado, pacotes irritantes que assumem que essas configurações estarão ativas quando novos desenvolvedores simplesmente rodarem install vão quebrar imediatamente
      Isso pode fazer com que parem com a prática de presumir que scripts podem ser executados

  • Pelo texto não fica claro, mas parece que a lista de permissões de scripts oferece suporte a permissão por pacote, e não só uma configuração global
    Deve ficar mais fácil manter políticas organizacionais que permitam scripts só para pacotes específicos
    Fico pensando se existe algum linter que possa ser usado para bloquear padrões inseguros nas configurações do gerenciador de pacotes desse jeito

    • grep não resolve?

  • Fico me perguntando se ainda existe algum motivo para usar Yarn
    Não sei se o Yarn também implementou proteções para impedir ataques à cadeia de suprimentos
    Até agora eu só conhecia o pnpm, então é bom ver o npm correndo atrás

    • Claro que existe
      A release 4.x mais recente do Yarn garante um comportamento determinístico quase ao ponto do exagero, e você pode esperar um comportamento consistente em toda a equipe
      Em termos de recursos, há muitos pequenos detalhes que, quando você se acostuma, acabam fazendo bastante diferença
      A próxima major também deve continuar nessa mesma direção, com desempenho melhor e recursos que até agora não dava para implementar sem depender desses ganhos de performance
      Para referência, sou o maintainer principal do Yarn
    • Trabalhei em um projeto que usava Yarn desde o começo até a v3, e é absurdamente lento, mas funciona
      Também tem recursos de proteção da cadeia de suprimentos
      No fim não aguentei e migrei para pnpm, e as instalações ficaram muito mais rápidas tanto no CI quanto nas máquinas locais de desenvolvimento
      Levei cerca de um dia para fazer a migração com ajuda de um LLM
    • Um dos diferenciais é a estratégia de instalação opcional, em que os pacotes não são extraídos em node_modules, mas executados diretamente de arquivos compactados
      https://yarnpkg.com/features/pnp
      É bem parecido com usar .jar em Java em vez de uma árvore de diretórios com arquivos .class
      Mas é um pouco gambiarra, e o suporte de editores e ferramentas varia bastante
      Como há muito menos arquivos pequenos, pode ser especialmente mais rápido se você for obrigado a trabalhar no Windows
      Também dá para colocar os arquivos no repositório git, eliminando a dependência de internet e de registros de pacotes
    • Não sei o que o NPM está fazendo, mas o Yarn é muito mais rápido para instalar dependências do que o NPM
    • Quem está dando downvote no meu comentário também pode responder à pergunta
      Eu realmente não sei a resposta

  • Eu não sabia que o npm era do GitHub
    Isso explica várias coisas

    • NPM Is Joining GitHub - https://news.ycombinator.com/item?id=22594549 (16 de março de 2020, 571 comentários, 1829 pontos) - https://github.blog/news-insights/company-news/npm-is-joinin...
      Algumas partes ficam interessantes de reler com o passar do tempo
      O comentário mais votado dizia algo como: “A Microsoft não acerta tudo, mas a aquisição do GitHub honestamente foi muito melhor do que eu esperava. Em vez de forçar políticas centradas na Microsoft no GitHub, a Microsoft acabou adotando mais coisas do GitHub na perspectiva de produto. O GitHub ainda opera como se fosse uma empresa separada”
    • A empresa NPM estava quase falindo em 2020
      Tinha recebido investimento de venture capital, mas não conseguiu encontrar um modelo de negócios sustentável
      O GitHub a adquiriu para salvar o ecossistema, e essa aquisição também quase não trouxe grande benefício para o GitHub
    • A maioria sabe disso, mas o que realmente explica muita coisa é que o GitHub pertence à Microsoft
      E a Microsoft moveu o GitHub para o Azure
    • Eu sabia que era do GitHub, mas foi a primeira vez que vi as notas de release diretamente no blog do GitHub, e não no blog do npm

  • Fico curioso se a lista de permissões no package.json fixa também a versão do pacote, ou se fixa só o nome do pacote

  • Bom ver que o padrão de allowScripts fica desativado
    [olha para o relógio] Só uns 18 meses atrás do pnpm, então?

    • O Maven do Java não tinha isso, e nunca senti que precisasse
      Para que isso serve no mundo JavaScript?