El paquete npm de todo
Un experimento con un paquete npm “de todo” que depende de decenas de miles de otros paquetes reveló un fallo en la política de despublicación de npm, bloqueando en la práctica a los mantenedores para retirar sus propios paquetes si algo depende de ellos mediante una versión comodín. Los comentaristas debaten cuánto de la culpa recae en el autor del paquete frente a las decisiones de diseño de npm, especialmente el manejo de las versiones `*` y la reacción heredada al incidente de left-pad. El episodio también reaviva preocupaciones más amplias sobre la cultura de microdependencias de JavaScript, la debilidad de la biblioteca estándar y la confianza en Semantic Versioning, lo que lleva a comparaciones con ecosistemas como Go, Rust, Maven, y a sugerencias como *vendoring*, mejores herramientas y normas más estrictas en torno a las dependencias.
Versionado de NPM “*” y política de despublicación
- La restricción de dependencia “*” junto con las reglas de despublicación de npm hace que un único paquete que depende de “todo” pueda, en la práctica, impedir que los autores despubliquen sus propios paquetes.
- Algunos lo llaman un “bug”; otros dicen que es intencional para evitar romper compilaciones cuando desaparecen versiones.
- Sugerencias:
- Interpretación más “suave” de
*para que se permita despublicar mientras quede al menos una versión. - Eliminaciones suaves / yanking: ocultar versiones de la resolución nueva mientras se siguen sirviendo para los lockfiles existentes.
- Revisión manual de las solicitudes de despublicación o prohibir la despublicación por completo salvo en casos de malware o legales.
- Interpretación más “suave” de
SemVer, fijación de versiones y fiabilidad
- Debate sobre cuán confiable es SemVer en el ecosistema de JS:
- Algunos ven roturas accidentales frecuentes y piensan que SemVer casi no significa nada.
- Otros informan que la mayoría de las actualizaciones menores/parches funcionan bien; las roturas son raras y se tratan como errores.
- Mitigación común: fijar versiones exactas y actualizar manualmente, usando SemVer solo como señal de intensidad de revisión.
- Fijar versiones no ayuda si una versión se despublica, de ahí la controversia sobre las reglas de despublicación.
Responsabilidad por el paquete “todo”
- Las opiniones van desde “experimento irresponsable/troleo” hasta “prueba de estrés legítima que expuso un diseño defectuoso de npm”.
- Muchos sostienen que el problema de fondo es la política de npm, no el experimento; algunos creen que el autor debe una explicación más detallada, otros ven innecesaria una disculpa más contundente.
Micro‑paquetes, cultura y riesgo
- Amplia crítica: microdependencias extremas y dependencia excesiva de paquetes triviales, que amplifican las roturas y el riesgo de seguridad.
- Algunos ven esto como algo cultural (“buscar una biblioteca para todo”), ligado a bibliotecas estándar débiles y a quirks históricos de los navegadores.
- Varios argumentan que los desarrolladores deberían ser más cautelosos y asumir la responsabilidad de las dependencias que añaden.
Mejoras propuestas para el ecosistema
- Bibliotecas estándar más fuertes y completas para reducir la necesidad de pequeños paquetes de utilidad.
- Puntuación social/de calidad de paquetes y grafos de dependencias, con advertencias por la explosión de dependencias transitivas.
- Hacer que reutilizar sea “lo bastante costoso” (tiempo, revisión) como para que los desarrolladores sientan el impacto de cada nueva dependencia.
- Incluir dependencias en el repositorio o fijarlas de forma más agresiva; herramientas como el proxy de módulos de Go, yanking y vetting de Cargo se citan como modelos positivos.