O Pacote NPM de Tudo
Um pacote experimental do npm para “tudo”, que depende de dezenas de milhares de outros pacotes, expôs uma falha na política de despublicação do npm, bloqueando na prática mantenedores de removerem seus próprios pacotes se qualquer coisa depender deles via versão curinga. Comentadores debatem o quanto a culpa recai sobre o autor do pacote versus as escolhas de design do npm, especialmente o tratamento de versões `*` e a reação herdada ao incidente do left-pad. O incidente também reacende preocupações mais amplas sobre a cultura de micro-dependências do JavaScript, a fraqueza da biblioteca padrão e a confiança no versionamento semântico, levando a comparações com ecossistemas como Go, Rust e Maven, além de sugestões como vendoring, melhores ferramentas e normas mais rígidas em torno de dependências.
Versionamento NPM “*” e Política de Despublicação
- A restrição de dependência “*” mais as regras de despublicação do npm significam que um único pacote que depende de “tudo” pode, na prática, impedir autores de despublicarem seus próprios pacotes.
- Alguns chamam isso de “bug”; outros dizem que é intencional para evitar quebrar builds quando versões desaparecem.
- Sugestões:
- Interpretação mais “suave” de
*, para que a despublicação seja permitida desde que pelo menos uma versão permaneça. - Soft deletes / yanking: ocultar versões da nova resolução, mas ainda servi-las para lockfiles existentes.
- Revisão manual para pedidos de despublicação ou proibir a despublicação por completo, exceto em casos de malware/legais.
- Interpretação mais “suave” de
SemVer, Fixação de Versões e Confiabilidade
- Debate sobre quão confiável o SemVer é no ecossistema JS:
- Alguns veem quebras acidentais frequentes e acham que SemVer é quase sem significado.
- Outros relatam que a maioria das atualizações minor/patch funciona bem; quebras são raras e tratadas como bugs.
- Mitigação comum: fixar versões exatas e atualizar manualmente, usando SemVer apenas como sinal para a intensidade da revisão.
- Fixar versões não ajuda se uma versão for despublicada, daí a controvérsia em torno das regras de despublicação.
Responsabilidade pelo Pacote “Everything”
- As opiniões vão de “experimento irresponsável/trolagem” a “teste de estresse legítimo que expôs um design defeituoso do npm”.
- Muitos argumentam que o problema raiz é a política do npm, não o experimento; alguns acham que o autor deve uma explicação mais detalhada, outros não veem necessidade de um pedido de desculpas mais forte.
Micro‑Pacotes, Cultura e Risco
- Amplamente criticado: dependências micro extremas e excesso de confiança em pacotes triviais, que amplificam quebras e risco de segurança.
- Alguns veem isso como cultural (“pegar uma biblioteca para tudo”), ligado a bibliotecas padrão fracas e a quirks históricos dos browsers.
- Vários argumentam que os desenvolvedores deveriam ser mais cautelosos e aceitar responsabilidade pelas dependências que adicionam.
Melhorias Propostas para o Ecossistema
- Bibliotecas padrão mais fortes e completas para reduzir a necessidade de pequenos pacotes utilitários.
- Pontuação social/de qualidade de pacotes e grafos de dependência, com avisos para explosão em deps transitivas.
- Tornar a reutilização “cara o suficiente” (tempo, revisão) para que os desenvolvedores sintam o impacto de cada nova dependência.
- Vendoring ou bloqueio de dependências de forma mais agressiva; ferramentas como o proxy de módulos do Go, yanking e vetting do Cargo são citadas como modelos positivos.