'everything' bloqueia devs de removerem seus próprios pacotes NPM
Um pacote de brincadeira chamado “everything” no registro npm declarou recentemente dependências em praticamente todos os outros pacotes, explorando uma política criada após o infame incidente do left-pad que impede despublicar módulos com dependentes. Isso efetivamente bloqueia mantenedores de apagar seus próprios pacotes e reacendeu o debate sobre como os registries devem lidar com exclusão, yanking e disponibilidade de código a longo prazo. Comentadores contrapõem o design do npm com alternativas como Cargo, PyPI e Maven, e ampliam a conversa para a complexidade da gestão de pacotes, a confiabilidade do ecossistema e se os desenvolvedores deveriam empacotar suas dependências localmente em vez de confiar em registries públicos.
Pacote “everything” do NPM e conflito com a política
- “Everything” depende de (quase) todos os outros pacotes NPM, acionando a regra do NPM de que pacotes com dependentes não podem ser despublicados.
- Comentadores observam que essa regra foi introduzida após o incidente do left-pad para proteger a confiabilidade do ecossistema.
- Resultado: autores de qualquer pacote do qual outros dependam perdem efetivamente a capacidade de apagá-lo, o que alguns veem como o NPM querendo “ter o bolo e comê-lo também”.
Pacotes deveriam poder ser apagados?
- Alguns argumentam que a exclusão deveria ser impossível depois da publicação; registries deveriam ter direitos perpétuos de distribuição.
- Outros querem mecanismos mais suaves:
- “Yanking”/soft-delete (como Cargo, NuGet, PyPI) para que lockfiles antigos ainda funcionem, mas novas resoluções evitem versões ruins.
- Flags de depreciação, ocultação na interface ou avisos claros em vez de remoções definitivas.
- Casos de uso para exclusão: bugs graves, descontinuação ou publicação acidental de conteúdo sensível ou embaraçoso.
- Contraponto: dados sensíveis já ficam expostos assim que enviados; a correção adequada é rotacionar segredos, não apagar.
Ideias de mitigação para este problema específico
- Propõem-se limites rígidos para o tamanho da árvore de dependências (por exemplo, com base no P99 do mundo real, com exceções).
- Outros apontam que isso não ajuda totalmente: um atacante pode simplesmente usar muitos pacotes pequenos “chunk”.
- Vários acham que a verdadeira solução é revisar a política de yank/unpublish do NPM, não limites de dependência.
- Alguns minimizam o impacto como um pequeno inconveniente; outros veem isso como uma falha sistêmica clara.
Debates mais amplos sobre gestão de pacotes e ecossistemas
- Comparações com PyPI, Cargo do Rust, Maven, NuGet, CPAN, Hackage, Nix, Bazel, Go modules.
- Muitos destacam que pacotes maliciosos ou problemáticos existem em todos os ecossistemas; o NPM não é único, mas sua escala e história tornam os problemas mais visíveis.
- Debate sobre um gerenciador de pacotes universal, agnóstico de linguagem:
- Defensores: especificação de dependências e entrega de arquivos são problemas genéricos.
- Opositores: o acoplamento profundo à semântica da linguagem, aos sistemas de build, ao comportamento de semver e aos modelos de segurança torna a unificação irrealista.
- Críticas fortes ao ecossistema JS/NPM como caótico e “pouco sério”, impulsionado por barreiras baixas de entrada, pacotes minúsculos e grafos de dependência profundos.
- Outros defendem o NPM como fundamentalmente bom, mas sobrecarregado pela popularidade e por escolhas de design legadas.