Busca en todas las páginas de la documentación
Todo backend de Node.js termina dependiendo de paquetes que no escribió, y la pregunta que realmente importa no es "¿hay una biblioteca para esto?" (casi siempre la hay), sino dónde pertenecen las dependencias, qué te promete realmente un número de versión y qué asumes cada vez que añades una.
Esta página es el razonamiento subyacente a las elecciones documentadas en otras partes de esta sección. Conceptos básicos de bibliotecas esenciales muestra el stack predeterminado concreto sobre el que se construye este recetario (zod, pino, got / axios, date-fns / Luxon, bullmq / ioredis), y cada una de esas páginas asume el modelo aquí descrito.
Algunos tiempos de ejecución vienen con "baterías incluidas", una gran biblioteca estándar que cubre servidores HTTP, JSON, criptografía, pruebas y más como un todo cohesivo. Node deliberadamente no tomó ese camino.
Los módulos principales de Node (node:fs, node:http, node:crypto, node:test y otros) se compilan en el propio binario, no necesitan instalación y se mantienen como parte del tiempo de ejecución. Pero el núcleo se queda corto en lo que necesita un backend real: no hay validación de esquemas, ni un registrador estructurado, ni un cliente HTTP con reintentos, ni una cola de trabajos. Esa brecha la llena el userland, el enorme ecosistema de paquetes publicados en npm, instalados en node_modules y versionados independientemente de Node.
Una forma útil de imaginarlo: el núcleo de Node es la estructura, los cimientos y el cableado de una casa (sólido, portante, poco probable que cambie), mientras que el userland es todo lo que eliges instalar dentro de ella: los accesorios de fontanería, los electrodomésticos, los muebles. Técnicamente podrías construir cualquiera de ellos por tu cuenta, pero casi nadie lo hace, porque el mercado ya ha producido opciones bien probadas y mantenidas para los más comunes.
import { readFile } from 'node:fs/promises'; // core: no se instala, viene con Node
import { z } from 'zod'; // userland: elegido, instalado, versionadoEsta división es la razón por la que las "bibliotecas esenciales" son un tema en sí mismo: la lista de dependencias de un backend no es un accidente de lo que se instaló en el camino, es un conjunto de elecciones deliberadas sobre qué brechas en el núcleo vale la pena llenar y con qué.
La pregunta de mayor impacto al elegir dónde debe comenzar y terminar la responsabilidad de una dependencia es: ¿es esto un límite o es lógica de dominio?
Un límite es cualquier punto donde los datos cruzan desde fuera del control de tu programa hacia él: un cuerpo de solicitud HTTP, una variable de entorno, un mensaje extraído de una cola, una respuesta de API de terceros. Los límites son exactamente donde la validación, el análisis y las bibliotecas defensivas como zod se ganan su lugar, porque la forma no confiable y los valores no confiables llegan allí primero. La lógica de negocio/dominio, por el contrario, opera con datos que ya has validado y normalizado; generalmente no debería necesitar reimportar una biblioteca de validación o adivinar la forma de una carga útil, porque ese trabajo ya se realizó en el borde.
// Límite: valida una vez, en el borde, antes de que cualquier otra cosa toque los datos
const OrderInput = z.object({ sku: z.string(), qty: z.number().int().positive() });
function handleCreateOrder(body: unknown) {
const input = OrderInput.parse(body); // lanza un error si la entrada es incorrecta - falla rápido, en el borde
return createOrder(input); // la lógica de dominio recibe un valor confiable y tipado
}Ese mismo instinto de límite se aplica al registro (estructurado, adyacente al límite, consulta pino), HTTP saliente (la política de reintentos/tiempo de espera pertenece al límite del cliente, consulta got / axios) y cargas útiles de cola (valida al entrar, igual que un cuerpo HTTP).
Debajo de cada npm install, el versionado semántico es el contrato que hace que un grafo de dependencias en constante crecimiento sea manejable: una cadena de versión MAYOR.MENOR.PARCHE promete que las versiones de parche corrigen errores sin cambiar el comportamiento, las versiones menores añaden capacidad sin romper el uso existente, y solo una versión mayor puede romper algo. package.json registra un rango aceptado (^7.2.0); el lockfile (package-lock.json o equivalente) fija el grafo exacto resuelto que realmente se instaló y probó; consulta Lockfiles y Reproducible Installs para saber cómo funciona ese fijado. Semver es una promesa que un mantenedor hace sobre su propio paquete, sin embargo, no es algo que npm verifique por ellos, y una versión mal etiquetada puede violarla.
Cada dependencia que añades también añade superficie a la cadena de suministro: código que no escribiste y no revisas línea por línea, ejecutándose con los mismos privilegios que tu propio código, arrastrado transitivamente por paquetes que sí elegiste deliberadamente. Un solo npm install puede resolver fácilmente cientos de paquetes transitivos a varios niveles de profundidad; Cadena de suministro: npm audit y Socket cubre la auditoría de ese grafo directamente; la decisión de bibliotecas esenciales de la que trata esta página está antes de eso: menos dependencias directas y mejor elegidas significan un grafo más pequeño para auditar en primer lugar.
El propio tiempo de ejecución ha ido reduciendo esta brecha con el tiempo: Node ha absorbido fetch, un ejecutor de pruebas incorporado (node:test) y (a partir de las líneas LTS recientes) node:sqlite, eliminando cada uno una categoría que solía requerir un paquete de terceros por defecto. Esa es una tendencia real que vale la pena seguir: la respuesta predeterminada correcta a "¿necesito una biblioteca para esto?" cambia a medida que el núcleo absorbe más de las solicitudes más comunes del userland, por lo que un stack que tenía sentido en una línea LTS anterior vale la pena revisarlo periódicamente en lugar de asumirlo como permanente.
No todas las decisiones de "añadir una dependencia" son iguales. Una biblioteca de propósito único y bien definida (zod para validación) es una apuesta muy diferente a un marco grande que incluye sus propias opiniones sobre enrutamiento, DI y configuración (NestJS); el caso del marco intercambia más control por más estructura, y es una decisión que generalmente se toma una vez al inicio de un servicio en lugar de incrementalmente.
| Enfoque | Fortaleza | Debilidad | Mejor ajuste |
|---|---|---|---|
| Solo núcleo de Node | Cero instalación, cero riesgo de terceros, siempre disponible | Faltan validación, registro estructurado, reintentos y más: brechas reales que debes llenar tú mismo | Scripts pequeños, herramientas sin una superficie de producción real |
| Biblioteca de propósito único | Pequeña huella, un trabajo claro, fácil de intercambiar más tarde | Tú mismo ensamblas y conectas varias de ellas | La mayoría de los servicios de producción: la postura predeterminada que documenta esta sección |
| Framework empaquetado (ej. NestJS) | Convenciones consistentes en un equipo grande, menos cableado individual | Mayor huella, más difícil de intercambiar una pieza más tarde, curva de aprendizaje más pronunciada | Equipos más grandes que valoran la consistencia sobre la flexibilidad incremental |
| Desarrollar tu propia solución | Exactamente el comportamiento que necesitas, sin dependencia de mantenimiento externo | Ahora eres dueño de las pruebas, los casos extremos y la revisión de seguridad para siempre | Problemas genuinamente novedosos sin un paquete existente bien mantenido |
Los entornos sensibles al arranque en frío (funciones sin servidor, tiempos de ejecución en el borde) añaden otro eje completamente diferente: el tamaño de instalación y el costo de importación de una dependencia importan allí de una manera que no lo hacen para un proceso de servidor de larga duración, lo cual es una razón más por la que vale la pena preguntar "¿necesita esto una biblioteca?" antes de "¿qué biblioteca?".
package.json es lo mismo que instalaciones reproducibles." package.json registra un rango aceptado; solo el lockfile fija el grafo exacto resuelto que realmente se probó; sin él, dos instalaciones del "mismo" package.json pueden resolverse de manera diferente.fetch incorporado de Node eliminó la necesidad de una biblioteca cliente HTTP." Reemplazó la necesidad de una solicitud HTTP básica en muchos casos, pero bibliotecas como got o axios aún añaden políticas de reintentos, interceptores y modelado de solicitudes/respuestas que fetch intencionalmente omite; consulta got / axios.Los módulos principales (node:fs, node:http y similares) se compilan en el binario de Node y no necesitan instalación. Los paquetes de usuario se publican en npm, se instalan en node_modules y se versionan independientemente de Node; la mayor parte de la capacidad real de un backend reside aquí.
Node mantuvo deliberadamente su núcleo pequeño y estable en lugar de "con baterías incluidas", dejando preocupaciones de rápido movimiento como la validación y el registro a un ecosistema que puede iterar independientemente del propio ciclo de lanzamiento de Node. Ha absorbido algunas de las necesidades más universales con el tiempo (fetch, node:test), pero la brecha de propósito general sigue siendo intencional.
Pregúntate si el problema se encuentra en un límite genuino (entrada no confiable, un sistema externo, una preocupación transversal como el registro) o si es lógica de negocio interna que una dependencia bien elegida en el límite ya debería haber hecho segura para trabajar.
Significa validar y normalizar los datos una vez, en el borde donde entran en tu programa (un cuerpo HTTP, una variable de entorno, un mensaje de cola), para que todo lo que esté aguas abajo pueda confiar en su forma en lugar de volver a verificarla. zod es la herramienta predeterminada de este recetario para ese límite.
Una versión MAYOR.MENOR.PARCHE implica: las versiones de parche corrigen errores sin cambiar el comportamiento, las versiones menores añaden capacidad sin romper el uso existente, y solo una versión mayor puede romper algo. Es una convención a la que se adhieren los mantenedores, no una garantía que npm verifica mecánicamente.
package.json registra un rango aceptado para cada dependencia; el lockfile fija las versiones exactas resueltas de todo el grafo de dependencias que realmente se instaló y probó. Sin el lockfile, el mismo package.json puede resolverse en un grafo diferente en una instalación diferente.
Es el conjunto completo de paquetes (directos y transitivos) que terminan ejecutándose dentro de tu proceso como resultado de tus elecciones. Una sola dependencia directa puede arrastrar docenas de otras que nunca elegiste explícitamente, cada una de las cuales ahora forma parte de tu superficie de seguridad y mantenimiento.
No del todo: fetch cubre bien el caso básico de solicitud/respuesta, pero bibliotecas como got y axios aún añaden políticas de reintentos, tiempos de espera ajustados para llamadas a servicios internos y ganchos de interceptación que fetch te deja para que los construyas tú mismo.
Cuando un equipo más grande se beneficia más de convenciones compartidas y aplicadas (enrutamiento, inyección de dependencias, estructura de módulos) que de la flexibilidad de elegir e intercambiar cada pieza de forma independiente; es un compromiso más pesado, que generalmente se hace una vez cerca del inicio de un servicio.
Sí, pero rara vez, principalmente cuando el problema es genuinamente novedoso y no existe un paquete bien mantenido que se ajuste, ya que desarrollar tu propia solución significa que ahora eres dueño de las pruebas, los casos extremos y la revisión de seguridad indefinidamente, un trabajo que la comunidad de una biblioteca mantenida ya realiza.
En un proceso de servidor de larga duración, el costo de importación de una dependencia se paga una vez al inicio y se amortiza durante un largo tiempo de actividad. En funciones sin servidor o de borde, ese costo puede pagarse en cada arranque en frío, lo que hace que el tamaño del paquete y el peso de la importación sean una preocupación de rendimiento mucho más directa.
La popularidad es una señal, no una garantía; vale la pena verificar por separado la actividad de mantenimiento, la rapidez con la que se parchean los avisos de seguridad y cuántos mantenedores tiene realmente un proyecto antes de tratarlo como un valor predeterminado seguro.
fetch por sí solo no cubreVersiones del stack: Esta página fue escrita para Node.js 24.18.0 (LTS activa), npm 10+ y TypeScript 5.6+.
Revisado por Chris St. John·Última actualización: 15 jul 2026