FAQs

JavaScript execution in a single Node process is single-threaded. libuv uses additional threads for I/O and its thread pool, but your JS callbacks run on one thread.

libuv wraps OS async primitives (epoll, kqueue, IOCP), drives the event loop phases, and runs a thread pool for blocking operations that have no async OS API.

All request handlers share the same JavaScript thread. A synchronous loop in one handler prevents others from running until it finishes.

One JS thread plus libuv's thread pool (default size 4, configurable via UV_THREADPOOL_SIZE).

No. await yields control back to the event loop; when the awaited I/O completes, the continuation is scheduled as a microtask on the same thread.

fetch uses the same libuv-backed network stack as node:http. It is non-blocking from JavaScript's perspective but still competes for the same event loop.

V8 is the JavaScript engine (also used in Chrome). Node adds libuv, built-in modules (fs, http, etc.), npm integration, and the module loader.

Scale pods/replicas horizontally for I/O-bound APIs. Add workers or bigger CPUs vertically when profiling shows CPU-bound hotspots on the main thread.

The V8 + libuv + event loop model is unchanged. Node 24 ships newer V8, stable fetch, and improved node:test - but the threading model is the same.

Non-blocking I/O excels for high-concurrency, I/O-bound workloads (APIs, proxies, streaming). CPU-heavy batch jobs may fit better on runtimes that default to thread pools.

Yes, if they call back into JavaScript synchronously or run long sync code in the addon. Profile with --trace-sync-io when investigating mysterious stalls.

Node.js 24.18.0 (Active LTS) for new deployments. Node 22.23.1 (Maintenance LTS) is acceptable during migration but plan to upgrade before maintenance ends.

Both swap Node versions via shell hooks. fnm is faster (written in Rust) and supports the same .nvmrc file format.

Yes. Commit .nvmrc or .node-version so every developer and CI job resolves the same version.

Add a volta section to package.json:

"volta": { "node": "24.18.0", "npm": "10.9.0" }

Volta switches automatically when you enter the project directory.

When engine-strict=true in .npmrc, npm refuses to install if the running Node/npm does not satisfy engines.

Yes. corepack enable activates the package manager version declared in packageManager field:

"packageManager": "pnpm@9.15.0"

Match CI to .nvmrc:

- uses: actions/setup-node@v4
  with:
    node-version-file: '.nvmrc'

fnm, nvm-windows, and Volta all support Windows. Document one canonical tool in the team README.

No for production. Odd releases are "Current" and short-lived. Use Active LTS (even numbers) for services.

npm list -g --depth=0

Prefer project-local devDependencies over globals for reproducibility.

Alpine uses musl libc - some native addons need extra build steps. bookworm-slim (Debian) is safer for native modules.

Upgrade dev machines and CI first, run the test suite, check deprecated API warnings with NODE_OPTIONS=--pending-deprecation, then roll production.

Node.js 24 (Active LTS), latest patch 24.18.0 as of this writing.

Yes during the Maintenance LTS window (through April 2027). Prefer Node 24 for new services.

Odd majors (23, 25) are "Current" - shorter support, more churn, and not covered by typical enterprise LTS policies.

Roughly every few weeks for security and bug fixes. Subscribe to nodejs-security announcements.

Active LTS backports V8 updates with new language features. Maintenance LTS is conservative - mostly fixes.

Node 20 reached End-of-Life. Upgrade to Node 22 (temporary) or Node 24 (target).

Check https://nodejs.org/en/about/previous-releases or the schedule.json in the Node.js GitHub repository.

Pin the full patch (24.18.0) or a digest for reproducibility. Floating 24 tags drift on every patch release.

Partially - but you still choose the runtime version in config. Verify it maps to Active or Maintenance LTS.

Node bundles OpenSSL; LTS patches include OpenSSL security updates. Running EOL Node means stale TLS primitives.

Possible but costly. Standardize on one Active LTS per org; allow Maintenance only during a timed migration.

Adopt each new Active LTS within 6 months of promotion. Exit Maintenance LTS at least 3 months before EOL.

Yes in Node 24. You can await fetch(...) directly at the prompt without an async wrapper.

Start with node --env-file=.env (Node 20+). Variables appear on process.env immediately.

The built-in REPL is JavaScript. Use npx tsx for a TypeScript-aware REPL.

-p evaluates and prints the expression (implies -e). node -p "2+2" outputs 4.

Press .break or Ctrl+C twice. .break aborts without killing the REPL session.

~/.node_repl_history by default. Set NODE_REPL_HISTORY to change the path.

In a project with "type": "module", use await import('pkg') instead of require.

After a thrown error, _error references it. console.error(_error) prints the stack.

No. Never open REPL on production servers - use read-only logs, metrics, and local reproduction instead.

Yes via NODE_REPL_HISTORY, custom repl servers, or programmatic repl.start({ prompt: 'api> ' }).

Copy the validated logic into a node:test file and replace manual console.log assertions with assert.equal.

Visit https://nodejs.org/docs/latest-v24.x/api/index.html or run node -p "process.version" and match the major in the version picker.

An environment variable enabling internal Node tracing. Common values: module, esm, http, net. Output goes to stderr.

Run with node --trace-warnings or set NODE_OPTIONS=--trace-warnings.

A JSON file with stack, heap, uv handles, and environment snapshot. Triggered on fatal errors or via SIGUSR2 when configured.

In the Node.js CHANGELOG on GitHub and in release blog posts for each major. Search for "Semver-Major".

NODE_DEBUG=esm shows import decisions. Also read package.json exports.

Search issues first. Open a new issue with reproduction version (node -v), platform, and minimal repro script.

Treats pending deprecations as active warnings - useful when preparing for the next major upgrade.

Run the same script on both versions with fnm exec 22.23.1 -- node script.mjs and fnm exec 24.18.0 -- node script.mjs.

node:fetch is documented under Web-compatible APIs. MDN covers API shape; Node docs cover Node-specific options.

https://nodejs.org/en/blog/vulnerability and the nodejs-sec mailing list.

Version drift is the root cause of most "works locally" incidents - wrong APIs, failed native builds, and unmatched security patches.

New services should use ESM on Node 24. CJS is legacy maintenance - exceptions need an ADR and sunset date.

Many libraries (Express in production mode, some log formatters) still branch on it. Set explicitly - do not rely on absence.

>=24.18.0 <25 for Node 24 Active LTS. During migration, document a temporary dual-range with an expiry date.

Treat critical/high severities as blockers. Fundamentals list focuses on runtime; see Security section for full policy.

Orchestrators may restart pods with stale images. Health output proves the running binary matches the intended patch.

Module-level singletons (DB pool, config) are fine. Per-request data on globals is not - use AsyncLocalStorage.

Add to .npmrc:

engine-strict=true

Allowed if production stays pinned Node 24 and CI tests against the production runtime - not dev-only shortcuts.

Every release candidate and within one week of any Node security advisory affecting your major line.

No. This list covers fundamentals; pair with Event Loop Best Practices for async performance.

status, node version, and build/git SHA. Optional: ltsPolicy field from your version gate script.