Por qué mis paquetes npm tienen cero dependencias

Cuando publiqué lightq-node, una cola de jobs para Node.js, lo primero que me preguntaron fue: ¿por qué no usas bull o bee-queue? La respuesta corta es que no quería que mis usuarios instalaran Redis sin pedírselo. Pero mientras lo pensaba me di cuenta de algo más profundo: tengo verdadero miedo de los árboles de dependencias que no controlo.

No es paranoia. En 2018, event-stream, un paquete con millones de descargas semanales, fue comprometido porque su autor lo cedió a un desconocido. El nuevo mantenedor inyectó código malicioso que robaba wallets de criptomonedas. El paquete en sí era inofensivo — el problema era uno de sus deps. Eso es supply chain attack, y le puede pasar a cualquiera.

El coste que nadie calcula

Imagina que publicas una librería con tres dependencias pequeñas. Cada una tiene las suyas. Antes de darte cuenta, tus usuarios tienen 40 paquetes en node_modules que no saben que existen. Cuando uno de esos 40 saca una versión rota, tú tienes una issue abierta aunque tu código no haya cambiado. Eso pasa constantemente.

El otro coste es más silencioso: el tiempo de auditoría. Si usas una dependencia con CVE, tienes que parchear aunque la vulnerabilidad no te afecte directamente. Si tienes cero dependencias, ese problema directamente no existe.

TypeScript compilado lo hace todo

La parte que más me sorprendió al escribir estos paquetes: casi todo lo que necesitaba ya estaba en Node.js core o era lo suficientemente simple como para implementarlo en un par de horas. El parser de cron de cron-scheduler-ts me llevó una tarde. Una cola con MinHeap y backoff exponencial, otra tarde. No hay magia detrás — son algoritmos básicos con buenos nombres.

// Así queda el package.json de cron-scheduler-ts
// Sin nada en "dependencies" — solo herramientas de desarrollo
{
  "name": "cron-scheduler-ts",
  "dependencies": {},
  "devDependencies": {
    "typescript": "^5.8.3",
    "tsup": "^8.4.0",
    "vitest": "^3.1.1"
  }
}

¿Cuándo sí merece la pena añadir una dep?

Tampoco me vuelvo loco. Si necesito un driver de base de datos o un cliente HTTP con soporte de retry y circuit breaker bien testeado, lo uso. La pregunta que me hago es: ¿cuánto tiempo me llevaría hacer esto bien, versus el riesgo de tener esta dep para siempre? Si la respuesta es 'más de dos días', acepto la dependencia. Si es 'una tarde', la implemento yo.

El resultado práctico: paquetes que se instalan en menos de un segundo, que nunca van a romper por un cambio en una dep transitiva, y cuyo código completo puedes leer en media hora. Para mí eso vale la inversión.