Search across all documentation pages
Every Node.js backend ends up depending on packages it didn't write, and the question that actually matters isn't "is there a library for this" - there almost always is - but where dependencies belong, what a version number is actually promising you, and what you're taking on every time you add one.
This page is the reasoning underneath the choices documented elsewhere in this section. Essential Libraries Basics shows the concrete default stack this cookbook builds around - zod, pino, got / axios, date-fns / Luxon, bullmq / ioredis - and each of those pages assumes the model described here.
Some runtimes ship "batteries included" - a large standard library that covers HTTP servers, JSON, cryptography, testing, and more as one cohesive whole. Node deliberately did not take that path.
Node's core modules (node:fs, node:http, node:crypto, node:test, and others) are compiled into the binary itself, need no installation, and are maintained as part of the runtime. But core stops well short of what a real backend needs: there's no schema validation, no structured logger, no retrying HTTP client, no job queue. That gap is filled by userland - the enormous ecosystem of packages published to npm, installed into node_modules, and versioned independently of Node itself.
A useful way to picture it: Node's core is the framing, foundation, and wiring of a house - solid, load-bearing, unlikely to change - while userland is everything you choose to install inside it: the plumbing fixtures, the appliances, the furniture. You could technically build your own of any of those, but almost nobody does, because the market has already produced well-tested, well-maintained options for the common ones.
import { readFile } from 'node:fs/promises'; // core: no install, ships with Node
import { z } from 'zod'; // userland: chosen, installed, versionedThis split is why "essential libraries" is its own subject at all - a backend's dependency list isn't an accident of whatever got installed along the way, it's a set of deliberate choices about which gaps in core are worth filling, and with what.
The single highest-leverage question when choosing where a dependency's responsibility should start and stop is: is this a boundary or is this domain logic?
A boundary is any point where data crosses from outside your program's control into it - an HTTP request body, an environment variable, a message pulled off a queue, a third-party API response. Boundaries are exactly where validation, parsing, and defensive libraries like zod earn their keep, because untrusted shape and untrusted values both arrive there first. Business/domain logic, by contrast, operates on data you've already validated and normalized - it generally shouldn't need to re-import a validation library or guess at a payload's shape, because that work already happened at the edge.
// Boundary: validate once, at the edge, before anything else touches the data
const OrderInput = z.object({ sku: z.string(), qty: z.number().int().positive() });
function handleCreateOrder(body: unknown) {
const input = OrderInput.parse(body); // throws on bad input - fails fast, at the edge
return createOrder(input); // domain logic receives a trusted, typed value
}That same boundary instinct applies to logging (structured, boundary-adjacent - see pino), outbound HTTP (retry/timeout policy belongs at the client boundary - see got / axios), and queue payloads (validate on the way in, same as an HTTP body).
Underneath every npm install, semantic versioning is the contract that makes an ever-growing dependency graph manageable at all: a version string MAJOR.MINOR.PATCH promises that patch releases fix bugs without changing behavior, minor releases add capability without breaking existing usage, and only a major release is allowed to break something. package.json records an accepted range (^7.2.0); the lockfile (package-lock.json or equivalent) pins the exact resolved graph that was actually installed and tested - see Lockfiles & Reproducible Installs for how that pinning actually works. Semver is a promise a maintainer makes about their own package, though - it's not something npm verifies for them, and a badly-tagged release can violate it.
Every dependency you add also adds supply chain surface: code you didn't write and don't review line-by-line, running with the same privileges as your own code, pulled in transitively by packages you did choose deliberately. A single npm install can easily resolve to hundreds of transitive packages several levels deep - Supply Chain: npm audit & Socket covers auditing that graph directly; the essential-libraries decision this page is about is upstream of that - fewer, better-chosen direct dependencies means a smaller graph to audit in the first place.
The runtime itself has been narrowing this gap over time: Node has absorbed fetch, a built-in test runner (node:test), and (as of recent LTS lines) node:sqlite, each removing a category that used to require a third-party package by default. That's a real trend worth tracking - the right default answer to "do I need a library for this" changes as core absorbs more of userland's most common requests, so a stack that made sense on an older LTS line is worth periodically revisiting rather than assumed permanent.
Not every "add a dependency" decision looks the same, either. A single-purpose, well-scoped library (zod for validation) is a very different bet than a large framework that bundles its own opinions about routing, DI, and configuration (NestJS) - the framework case trades more control for more structure, and is a decision usually made once at a service's inception rather than incrementally.
| Approach | Strength | Weakness | Best Fit |
|---|---|---|---|
| Node core only | Zero install, zero third-party risk, always available | Missing validation, structured logging, retries, and more - real gaps to fill yourself | Small scripts, tools with no real production surface |
| Single-purpose library | Small footprint, one clear job, easy to swap later | You assemble and wire several of them yourself | Most production services - the default posture this section documents |
| Bundled framework (e.g. NestJS) | Consistent conventions across a large team, less individual wiring | Heavier footprint, harder to swap one piece later, steeper onboarding | Larger teams that value consistency over incremental flexibility |
| Roll your own | Exactly the behavior you need, no external maintenance dependency | You now own testing, edge cases, and security review forever | Genuinely novel problems with no well-maintained existing package |
Cold-start-sensitive environments (serverless functions, edge runtimes) add another axis entirely: a dependency's install size and import cost matter there in a way they don't for a long-lived server process, which is one more reason "does this need a library at all" is worth asking before "which library."
package.json is the same as reproducible installs." package.json records an accepted range; only the lockfile pins the exact resolved graph that was actually tested - without it, two installs of the "same" package.json can resolve differently.fetch removed the need for an HTTP client library." It replaced the need for a bare HTTP request in many cases, but libraries like got or axios still add retry policy, interceptors, and request/response shaping that fetch intentionally leaves out - see got / axios.Core modules (node:fs, node:http, and similar) are compiled into the Node binary and need no installation. Userland packages are published to npm, installed into node_modules, and versioned independently of Node itself - most of a backend's actual capability lives here.
Node deliberately kept its core small and stable rather than "batteries included," leaving fast-moving concerns like validation and logging to an ecosystem that can iterate independently of Node's own release cycle. It has absorbed some of the most universal needs over time (fetch, node:test), but the general-purpose gap remains intentional.
Ask whether the problem sits at a genuine boundary - untrusted input, an external system, a cross-cutting concern like logging - versus being internal business logic that a well-chosen dependency at the boundary should already have made safe to work with.
It means validating and normalizing data once, at the edge where it enters your program (an HTTP body, an environment variable, a queue message), so that everything downstream can trust its shape instead of re-checking it. zod is this cookbook's default tool for that boundary.
A MAJOR.MINOR.PATCH version implies: patch releases fix bugs without behavior change, minor releases add capability without breaking existing usage, and only a major release may break something. It's a convention maintainers opt into, not a guarantee npm mechanically verifies.
package.json records an accepted range for each dependency; the lockfile pins the exact resolved versions of the entire dependency graph that was actually installed and tested. Without the lockfile, the same package.json can resolve to a different graph on a different install.
It's the full set of packages - direct and transitive - that end up running inside your process as a result of your choices. A single direct dependency can pull in dozens of others you never explicitly chose, each one now part of your security and maintenance surface.
Not entirely - fetch covers the basic request/response case well, but libraries like got and axios still add retry policies, timeouts tuned for internal service calls, and interceptor hooks that fetch leaves for you to build yourself.
When a larger team benefits more from shared, enforced conventions (routing, dependency injection, module structure) than from the flexibility of choosing and swapping each piece independently - it's a heavier commitment, usually made once near a service's inception.
Yes, but rarely - mainly when the problem is genuinely novel and no well-maintained package fits, since rolling your own means you now own testing, edge cases, and security review indefinitely, work a maintained library's community already does.
In a long-lived server process, a dependency's import cost is paid once at startup and amortized over a long uptime. In serverless or edge functions, that cost can be paid on every cold start, making package size and import weight a much more direct performance concern.
Popularity is a signal, not a guarantee - it's worth separately checking maintenance activity, how quickly security advisories get patched, and how many maintainers a project actually has before treating it as a safe default.
fetch alone doesn't coverStack versions: This page was written for Node.js 24.18.0 (Active LTS), npm 10+, and TypeScript 5.6+.
Reviewed by Chris St. John·Last updated Jul 15, 2026