'everything' bloquea a los desarrolladores de eliminar sus propios paquetes de NPM
Un paquete de broma llamado “everything” en el registro de npm declaró recientemente dependencias sobre prácticamente todos los demás paquetes, aprovechando una política diseñada tras el famoso incidente de left-pad que impide despublicar módulos con dependientes. Esto bloquea efectivamente a los mantenedores para borrar sus propios paquetes y ha reavivado el debate sobre cómo deberían los registros gestionar borrados, yanking y la disponibilidad a largo plazo del código. Los comentaristas contrastan el diseño de npm con alternativas como Cargo, PyPI y Maven, y amplían la conversación a la complejidad de la gestión de paquetes, la fiabilidad del ecosistema y si los desarrolladores deberían versionar localmente sus dependencias en lugar de confiar en registros públicos.
Choque entre el paquete “everything” de NPM y la política
- “Everything” depende de (casi) todos los demás paquetes de NPM, activando la regla de NPM según la cual los paquetes con dependientes no pueden ser despublicados.
- Los comentaristas señalan que esta regla se introdujo después del incidente de left-pad para proteger la fiabilidad del ecosistema.
- Resultado: los autores de cualquier paquete del que dependa algo pierden efectivamente la capacidad de borrarlo, lo que algunos ven como que NPM quiere “tener el pastel y comérselo también”.
¿Deberían poder borrarse los paquetes?
- Algunos sostienen que el borrado debería ser imposible una vez publicado; los registros deberían tener derechos de distribución perpetuos.
- Otros quieren mecanismos más suaves:
- “Yanking”/borrado suave (como Cargo, NuGet, PyPI) para que los viejos lockfiles sigan funcionando pero las nuevas resoluciones eviten versiones malas.
- Banderas de obsolescencia, ocultarlo en la interfaz o advertencias claras en lugar de eliminaciones duras.
- Casos de uso para borrar: fallos graves, obsolescencia o publicación accidental de contenido sensible o embarazoso.
- Contraargumento: los datos sensibles ya quedan expuestos una vez subidos; la solución correcta es rotar secretos, no borrar.
Ideas de mitigación para este problema específico
- Se proponen límites duros al tamaño del árbol de dependencias (por ejemplo, basados en el P99 del mundo real, con excepciones).
- Otros señalan que esto no ayuda del todo: un atacante podría simplemente usar muchos paquetes pequeños “chunk”.
- Varios opinan que la solución real es revisar la política de yanking/despublicación de NPM, no los límites de dependencias.
- Algunos minimizan el impacto como una molestia leve; otros lo ven como un fallo sistémico claro.
Debates más amplios sobre gestión de paquetes y ecosistemas
- Comparaciones con PyPI, Cargo de Rust, Maven, NuGet, CPAN, Hackage, Nix, Bazel, módulos de Go.
- Muchos destacan que existen paquetes maliciosos o problemáticos en todos los ecosistemas; NPM no es único, pero su escala e इतिहास lo hacen más visible.
- Debate sobre un gestor de paquetes universal e independiente del lenguaje:
- Defensores: la especificación de dependencias y la entrega de archivos son problemas genéricos.
- Opositores: el acoplamiento profundo con la semántica del lenguaje, los sistemas de compilación, el comportamiento de semver y los modelos de seguridad hace que la unificación sea irrealista.
- Fuerte crítica al ecosistema JS/NPM como caótico y “poco serio”, impulsado por barreras de entrada bajas, paquetes diminutos y gráficos de dependencias profundos.
- Otros defienden NPM como algo fundamentalmente bueno pero desbordado por su popularidad y decisiones de diseño heredadas.