Expert Node.js Interview Questions and Answers

V8 Internals V8 is Google’s open-source JavaScript and WebAssembly engine, written in C++. Node.js embeds V8 to execute JavaScript code.

V8 compilation pipeline:

• Parsing — JavaScript source is parsed into an Abstract Syntax Tree (AST). V8 uses lazy parsing: functions are only fully parsed when called (except exported functions and IIFEs).
• Ignition (bytecode interpreter) — the AST is compiled to bytecode and executed by the Ignition interpreter. Fast to start, not the fastest to run.
• TurboFan (optimising JIT compiler) — functions called frequently (hot functions) are identified and compiled by TurboFan to highly optimised native machine code. This is just-in-time (JIT) compilation.
• Deoptimisation — if V8’s type assumptions are violated (e.g., an array that was always ints suddenly gets a string), TurboFan deoptimises back to Ignition. This is why monomorphic code (consistent types) is faster.

// Help V8 optimise — consistent types
function add(a, b) { return a + b; }
add(1, 2);   // V8 assumes Number + Number
add(3, 4);   // confirms — TurboFan optimises
add('x', 2); // type change — deoptimisation triggered

// Use --v8-options to list V8 flags
// node --v8-options | grep 'trace-opt'
// node --trace-opt server.js  — shows which functions TurboFan optimises

Internals libuv is a cross-platform C library that powers Node.js’s asynchronous I/O operations. V8 runs JavaScript but cannot interact with the OS; libuv provides the event loop, thread pool, and system call abstractions.

libuv components:

• Event loop — the core loop that polls for I/O readiness using OS-specific mechanisms: epoll (Linux), kqueue (macOS/BSD), IOCP (Windows)
• Thread pool — a pool of 4 threads (configurable via UV_THREADPOOL_SIZE) for operations the OS cannot do asynchronously: file I/O, DNS resolution (dns.lookup), some crypto operations, fs.stat
• Handles and requests — handles represent long-lived objects (TCP connections, timers); requests represent short-lived operations (a write to a socket)
• Timer implementation — setTimeout/setInterval are implemented in libuv using a binary heap of timer callbacks

# Increase thread pool size for file-heavy workloads
UV_THREADPOOL_SIZE=16 node server.js

# Why this matters: if you have 4 threads and 10 concurrent fs.readFile()
# calls, 6 will queue and wait. Increasing the pool helps I/O-heavy workloads.

Memory Node.js memory is managed by V8’s garbage collector. Understanding it helps diagnose memory leaks and tune performance.

Heap structure:

• New Space (Young Generation) — small (~1-8MB), frequently collected (Scavenge GC). Short-lived objects live here. Most objects die young.
• Old Space (Old Generation) — objects that survived 2+ Scavenge cycles are promoted here. Collected by Major GC (Mark-Sweep-Compact). Larger, less frequent.
• Large Object Space — objects exceeding the size threshold (typically 256KB) that would not fit in a normal page.
• Code Space — JIT-compiled code from TurboFan.

# Default heap limit (~1.5GB on 64-bit)
node --max-old-space-size=4096 server.js  # set to 4GB

# Monitor GC activity
node --expose-gc --trace-gc server.js

# Force GC (development/testing only — NEVER in production)
if (global.gc) global.gc();

// Check heap usage
const v8 = require('v8');
const stats = v8.getHeapStatistics();
console.log({
  used:   Math.round(stats.used_heap_size / 1024 / 1024) + 'MB',
  total:  Math.round(stats.total_heap_size / 1024 / 1024) + 'MB',
  limit:  Math.round(stats.heap_size_limit / 1024 / 1024) + 'MB'
});

Common memory leaks: closures holding references to large objects, event listeners not removed (EventEmitter.off()), global variables, timers not cleared, circular references in Buffers, keeping references in Maps/Sets without clearing them.

Event Loop Microtask starvation occurs when the microtask queue (Promises, queueMicrotask, process.nextTick) is continuously refilled, preventing the event loop from ever advancing to its I/O and timer phases. The server stops processing new requests.

// ❌ DANGER: recursive Promise chain — starves event loop
async function recursiveAsync() {
  await Promise.resolve(); // queues to microtask queue
  recursiveAsync();        // immediately queues another
  // event loop NEVER proceeds to I/O phase — all HTTP requests hang
}

// ❌ Same with process.nextTick
function starveTick() {
  process.nextTick(starveTick); // fills nextTick queue infinitely
}

// ✅ FIX: use setImmediate to yield to I/O between iterations
async function safeBatch(items) {
  for (const item of items) {
    await processItem(item);
    // Yield to event loop every 100 items
    if (items.indexOf(item) % 100 === 0) {
      await new Promise(resolve => setImmediate(resolve));
    }
  }
}

// ✅ FIX for CPU work: use setImmediate to release the event loop
function processLargeArray(arr, callback) {
  let i = 0;
  function doChunk() {
    let n = 1000; // process 1000 items per tick
    while (n-- && i < arr.length) process(arr[i++]);
    if (i < arr.length) setImmediate(doChunk); // yield, then continue
    else callback();
  }
  setImmediate(doChunk);
}

Native N-API (now called Node-API) is a stable C API for building native Node.js addons — modules written in C/C++ (or Rust via napi-rs) that are callable from JavaScript.

Why Node-API matters:

• ABI stability — N-API is ABI-stable across Node.js versions. Before N-API, native addons broke on every Node.js version upgrade because they depended on V8’s internal API (which changes). N-API addons compiled for Node 14 work on Node 20.
• Language bridging — call C++ libraries (OpenCV, TensorFlow, libsodium) or Rust crates from JavaScript
• Performance-critical code — offload CPU-intensive work to native code

// Native addon written with node-addon-api (C++ wrapper for N-API)
// addon.cc
#include <napi.h>

Napi::Value Add(const Napi::CallbackInfo& info) {
  Napi::Env env = info.Env();
  double arg0 = info[0].As<Napi::Number>().DoubleValue();
  double arg1 = info[1].As<Napi::Number>().DoubleValue();
  return Napi::Number::New(env, arg0 + arg1);
}

Napi::Object Init(Napi::Env env, Napi::Object exports) {
  exports.Set("add", Napi::Function::New(env, Add));
  return exports;
}
NODE_API_MODULE(addon, Init)

// Usage from JavaScript
const addon = require('./build/Release/addon');
console.log(addon.add(3, 4)); // 7

// Modern approach: napi-rs (Rust → Node.js) or ffi-napi (call .so/.dll directly)

Security The Permission Model (experimental in Node.js 20, maturing in Node 22+) restricts what resources a Node.js process can access at runtime — file system paths, network, child processes, workers, and native addons. Similar to Deno’s permission system.

# Run with specific permissions only
node --experimental-permission server.js
# By default ALL access is blocked

# Grant read access to specific directory
node --experimental-permission \
     --allow-fs-read=/app/public \
     server.js

# Grant write access
node --experimental-permission \
     --allow-fs-write=/app/logs \
     --allow-fs-read=/app \
     server.js

# Allow network access (optional — can restrict to specific hosts)
node --experimental-permission \
     --allow-net \
     server.js

# Allow child process spawning
node --experimental-permission \
     --allow-child-process \
     server.js

# Allow worker threads
node --experimental-permission \
     --allow-worker \
     server.js

// Check permissions programmatically
const { permission } = require('node:process');
console.log(permission.has('fs.read', '/app/data')); // true/false

// Attempt blocked operation → throws an error
try { fs.readFileSync('/etc/passwd'); }
catch (e) { console.error(e.code); } // ERR_ACCESS_DENIED

The Permission Model is valuable for running untrusted scripts, multi-tenant systems, and hardening production containers by applying the principle of least privilege.

Tooling Corepack is a Node.js built-in tool (included since Node.js 16.9+) that manages the version of npm, Yarn, or pnpm used in a project — ensuring everyone on the team uses the exact same package manager version without global installs.

# Enable Corepack (disabled by default)
corepack enable

# package.json — specify package manager and version
{
  "packageManager": "pnpm@9.1.0"
}

# Now pnpm is automatically downloaded and used at the specified version
pnpm install     # uses pnpm 9.1.0 exactly (downloaded if not cached)

# Prepare a specific version (pre-download for offline use)
corepack prepare pnpm@9.1.0 --activate

# Switch between package managers per project
echo '{"packageManager": "yarn@4.2.2"}' > package.json
yarn install  # Corepack downloads Yarn 4.2.2

# Why this matters:
# Without Corepack, developers each install different npm/yarn/pnpm versions
# This causes lockfile format differences, inconsistent behaviour, and CI/CD issues
# Corepack pins the package manager version just like node engines pins Node

Modules When you call require('some-module'), Node.js follows a specific resolution algorithm to find the file:

// require('./utils') — relative path resolution
// 1. Try exact: ./utils.js → ./utils.json → ./utils.node
// 2. Try directory: ./utils/index.js → ./utils/index.json → ./utils/index.node
// 3. Check package.json "main" field in ./utils/package.json

// require('express') — bare specifier (npm package)
// Starting from current directory, walk UP the tree:
// ./node_modules/express → ../node_modules/express → ../../node_modules/express
// Until reaching the filesystem root or finding the module

// Inside node_modules/express/:
// 1. Check package.json "main" field → e.g., "./index.js"
// 2. Fall back to index.js, index.json, index.node

// require('/absolute/path/to/file') — absolute path
// Tries .js, .json, .node extensions if no extension given

// package.json "exports" field (modern — overrides "main")
// Enables conditional exports: different files for CJS vs ESM, browser vs Node
{
  "exports": {
    ".":           { "import": "./dist/index.mjs", "require": "./dist/index.cjs" },
    "./utils":     "./dist/utils.js",
    "./package.json": "./package.json"
  }
}
// require('mylib')         → dist/index.cjs
// import 'mylib'           → dist/index.mjs
// import 'mylib/utils'     → dist/utils.js
// import 'mylib/internal'  → ❌ not exported — blocked

Memory

Step 1 — Detect: watch memory usage over time

// Add memory monitoring to your app
setInterval(() => {
  const mem = process.memoryUsage();
  logger.info({
    rss:      Math.round(mem.rss      / 1024 / 1024) + 'MB', // total process memory
    heapUsed: Math.round(mem.heapUsed / 1024 / 1024) + 'MB', // JS heap in use
    heapTotal:Math.round(mem.heapTotal/ 1024 / 1024) + 'MB', // total JS heap
    external: Math.round(mem.external / 1024 / 1024) + 'MB'  // C++ objects (Buffers)
  }, 'Memory usage');
}, 30000); // log every 30s — a rising heapUsed trend indicates a leak

Step 2 — Isolate: heap snapshots in Chrome DevTools

node --inspect server.js
# Open chrome://inspect → Memory tab → Take heap snapshot
# Apply load with autocannon, take another snapshot
# "Comparison" view shows which object types grew
# Look for: detached DOM nodes, growing arrays, uncleaned event listeners

Step 3 — Common causes and fixes:

• Event listeners not removed → emitter.off() in cleanup
• Timer not cleared → clearInterval() / clearTimeout()
• Growing global Map/Set → add TTL or max-size eviction
• Closures capturing large objects → null the reference when done
• Unclosed streams → always handle end/close/error events
• Promise chains not completing → add .catch() and timeouts

// Tool: clinic.js — automated profiling suite
npm install -g clinic
clinic doctor -- node server.js   # detects I/O, event loop, memory issues
clinic heap -- node server.js     # heap profiler
clinic flame -- node server.js    # CPU flame graph

Security

• Prototype pollution prevention — never merge untrusted objects into existing objects. Use Object.create(null) for safe maps without __proto__. Validate with no-prototype-builtins ESLint rule.
• Dependency security — run npm audit in CI/CD. Automate with Snyk or Dependabot. Prefer packages with a small, well-maintained dependency tree.
• ReDoS (RegEx DoS) — avoid catastrophically backtracking regular expressions that can hang the event loop on malicious input. Use the safe-regex package to detect them.
• Timing attacks — use crypto.timingSafeEqual() for comparing secrets/hashes. Standard string comparison (===) leaks timing information.
• Path traversal — sanitise file path inputs. Use path.resolve() and verify the result starts with your intended directory.
• SSRF (Server-Side Request Forgery) — validate URLs before making outbound requests. Block private IP ranges (169.254.x.x, 10.x.x.x).
• Environment variables — never log process.env. Use secrets managers (AWS Secrets Manager, HashiCorp Vault) in production.
• Least privilege — run Node.js as a non-root user. Use the Permission Model. Scope IAM roles to minimum required permissions.

// Path traversal prevention
function safeReadFile(userPath) {
  const safeBase = path.resolve('/app/uploads');
  const requested = path.resolve(safeBase, userPath);
  if (!requested.startsWith(safeBase)) {
    throw new Error('Path traversal detected');
  }
  return fs.readFileSync(requested);
}

Async Context async_hooks provide lifecycle hooks for every async resource created in Node.js — init, before, after, destroy, promiseResolve. They are the internal mechanism behind AsyncLocalStorage and are used by APM tools for distributed tracing.

const async_hooks = require('async_hooks');
const fs = require('fs');

// Track async resource lifetimes (low-level, rarely used directly)
const hook = async_hooks.createHook({
  init(asyncId, type, triggerAsyncId, resource) {
    fs.writeSync(1, `init: asyncId=${asyncId} type=${type} trigger=${triggerAsyncId}\n`);
    // type: PROMISE, TCPWRAP, TIMERWRAP, HTTPPARSER, etc.
  },
  before(asyncId) {
    fs.writeSync(1, `before: asyncId=${asyncId}\n`);
  },
  after(asyncId) {
    fs.writeSync(1, `after: asyncId=${asyncId}\n`);
  },
  destroy(asyncId) {
    fs.writeSync(1, `destroy: asyncId=${asyncId}\n`);
  }
});
hook.enable();

// Note: console.log is NOT safe inside async_hooks callbacks (it's async!)
// Use fs.writeSync (synchronous) for debugging inside hooks

// WHY ASYNC_HOOKS MATTERS:
// AsyncLocalStorage (lesson 2) is built on async_hooks
// OpenTelemetry uses async_hooks to propagate trace context
// APM tools (Datadog, New Relic) use it to track all async operations

// Most developers use AsyncLocalStorage instead of raw async_hooks
const { AsyncLocalStorage } = require('async_hooks');
// (Prefer this — safe, stable, simpler API)

Performance Cold start time matters in serverless functions (AWS Lambda, Vercel, Cloud Run) where every invocation may start a fresh Node.js process.

Optimisation techniques:

• Lazy require() — only load modules when first needed, not at startup
• V8 code cache — Node.js can serialize V8’s compiled bytecode to disk (--code-cache-path flag), skipping recompilation on restart
• Node.js Single Executable Application (SEA) — Node 20+ can bundle an app into a single self-contained executable, eliminating module resolution overhead
• Reduce dependencies — each require() costs time (file I/O + parsing). Use bundle tools like esbuild or ncc to create a single-file bundle

# Bundle the entire app to a single file (no node_modules at runtime)
npx @vercel/ncc build src/server.js -o dist/
# Result: dist/index.js — single file with all dependencies inlined

# Measure startup time
time node -e "require('./src/server')"

# Profile startup with --cpu-prof
node --cpu-prof --cpu-prof-interval=100 server.js
# Generates a .cpuprofile file — open in Chrome DevTools Performance tab

# V8 startup snapshot (experimental Node 20+)
# Serialise initialised heap state to a snapshot file
# Future processes restore from snapshot — skipping init work

Packaging Node.js 20+ supports bundling an application into a standalone executable that includes Node.js itself — no Node.js installation required on the target machine. Similar to Deno’s deno compile.

// 1. Create SEA configuration
// sea-config.json
{
  "main": "dist/app.js",          // entry point (must be a single bundled file)
  "output": "sea-prep.blob",      // intermediate blob
  "disableExperimentalSEAWarning": true,
  "useSnapshot": false,
  "useCodeCache": true            // cache V8 bytecode for faster startup
}

// 2. Bundle your app first (SEA requires a single file)
npx esbuild src/server.js --bundle --platform=node --outfile=dist/app.js

// 3. Generate the blob
node --experimental-sea-config sea-config.json

// 4. Copy the Node.js binary and inject the blob
cp $(which node) my-app
# On macOS — remove existing signature:
codesign --remove-signature my-app
# Inject the blob:
npx postject my-app NODE_SEA_BLOB sea-prep.blob \
  --sentinel-fuse NODE_SEA_FUSE_fce680ab2cc467b6e072b8b5df1996b2 \
  --macho-segment-name NODE_SEA

// 5. Distribute and run — no Node.js needed on target machine
./my-app

SEA is ideal for CLI tools, desktop apps, and container images where you want a single binary with no runtime dependency.

Events EventEmitter is synchronous by design — emit() calls all listeners synchronously in the order they were registered, returning only after all listeners complete. This surprises many developers who expect asynchronous behaviour.

const { EventEmitter } = require('events');
const emitter = new EventEmitter();

emitter.on('data', (val) => console.log('listener 1:', val));
emitter.on('data', (val) => console.log('listener 2:', val));

console.log('before emit');
emitter.emit('data', 'hello'); // SYNCHRONOUS — all listeners run before returning
console.log('after emit');

// Output:
// before emit
// listener 1: hello
// listener 2: hello
// after emit  ← NOT before the listeners!

// ❌ DANGER: async listener throws — unhandled error
emitter.on('data', async (val) => {
  await doSomething();
  throw new Error('oops'); // this is an UNHANDLED rejection — not caught by emit()
});

// ✅ Handle async errors in async listeners
emitter.on('data', async (val) => {
  try {
    await doSomething();
  } catch (err) {
    emitter.emit('error', err); // propagate to error listener
  }
});

// EventEmitterAsyncResource (Node 17+) — integrates async context tracking
// with EventEmitter so that async listeners preserve AsyncLocalStorage context

Ecosystem

• Major versions — released every 6 months. Even-numbered versions (18, 20, 22) become LTS (Long-Term Support); odd-numbered versions (17, 19, 21) are short-lived Current releases.
• LTS lifecycle — Active LTS: 18 months after release (bug fixes, security patches). Maintenance LTS: 12 more months (security patches only). Total: ~3 years of support per LTS version.
• Current — latest features, 6 months of support. Use only for experimentation.

# Check current version
node --version

# Node.js 20 LTS (Codename: Iron)   — Active LTS until April 2025, Maintenance until April 2026
# Node.js 22 LTS (Codename: Jod)    — Active LTS until April 2026, Maintenance until April 2027
# Node.js 24                        — Current release (2025-2026)

# Use nvm (Node Version Manager) to manage multiple versions
nvm install 22          # install latest Node 22
nvm use 22              # switch to Node 22
nvm alias default 22    # set as default
nvm ls                  # list installed versions

# .nvmrc file — pin project to specific version
echo "22" > .nvmrc
nvm use  # reads .nvmrc automatically

For production: always use the current Active LTS version. Upgrade to the next LTS within 3-6 months of its release to stay ahead of end-of-life. Use CI to test against multiple Node versions (node-version: [20, 22] in GitHub Actions).

Security The Node.js Policy feature (experimental) allows you to define an integrity check policy for loaded modules — ensuring every require()d file matches a pre-computed hash. This prevents supply chain attacks where a dependency is compromised after installation.

// policy.json — define allowed modules and their integrity hashes
{
  "resources": {
    "./server.js": {
      "integrity": "sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
    },
    "node_modules/express/index.js": {
      "integrity": "sha384-EXPECTED_HASH_HERE"
    }
  }
}

# Run with the policy
node --experimental-policy=policy.json server.js
# If any file doesn't match its hash → ERR_MANIFEST_ASSERT_INTEGRITY error

# Generate hashes for existing files
node -e "
  const crypto = require('crypto');
  const content = require('fs').readFileSync('./server.js');
  const hash = crypto.createHash('sha384').update(content).digest('base64');
  console.log('sha384-' + hash);
"

While still experimental, the Policy feature is one defence against attacks like event-stream (2018) where a popular npm package was compromised after transfer to a malicious maintainer. In practice, combine with npm audit, Sigstore/npm provenance, and lockfile integrity checking.

Error Handling

// uncaughtException — synchronous throw that reached the top of the call stack
process.on('uncaughtException', (err, origin) => {
  // err    = the Error object
  // origin = 'uncaughtException' or 'unhandledRejection'
  logger.fatal({ err, origin }, 'Uncaught exception — process will exit');
  // Clean up synchronously (close DB connections, flush logs)
  // Then EXIT — the process is now in an undefined state and must restart
  process.exit(1);
});

// unhandledRejection — Promise rejected without a .catch() or try/catch
process.on('unhandledRejection', (reason, promise) => {
  // In Node.js <15: printed a warning
  // In Node.js 15+: CRASHES the process by default (converted to uncaughtException)
  logger.error({ reason, promise }, 'Unhandled promise rejection');
  // Best practice: fix the root cause (add .catch()) rather than handling here
});

// rejectionHandled — fired when a previously-unhandled rejection gets a handler attached
process.on('rejectionHandled', (promise) => {
  logger.warn('Promise rejection handled late:', promise);
});

// Best practice: these are LAST RESORT handlers, not error handling strategies
// Fix unhandledRejection at source:
async function doWork() {
  try {
    await riskyOperation();
  } catch (err) {
    // handle here — don't let it propagate to unhandledRejection
    logger.error(err);
  }
}

ESM In ES Modules, the CommonJS globals __dirname, __filename, require, and module are NOT available. import.meta provides module-level metadata as the ESM equivalent.

// ESM module (file.mjs or type: "module" in package.json)
import { fileURLToPath } from 'url';
import { dirname }       from 'path';
import { createRequire } from 'module';

// __filename equivalent in ESM
const __filename = fileURLToPath(import.meta.url);
// import.meta.url = "file:///home/user/app/server.mjs"
// __filename       = "/home/user/app/server.mjs"

// __dirname equivalent in ESM
const __dirname = dirname(__filename);
// __dirname = "/home/user/app"

// require() equivalent in ESM (to load CJS modules)
const require = createRequire(import.meta.url);
const config  = require('./config.json'); // load JSON the CJS way

// Other import.meta properties (bundler-specific)
console.log(import.meta.url);  // file URL of this module
// import.meta.env  — Vite-specific (environment variables)
// import.meta.hot  — Vite HMR API
// import.meta.dirname  — Available in Node.js 21.2+ (no fileURLToPath needed!)
// import.meta.filename — Available in Node.js 21.2+

Architecture

• Graceful shutdown — stop accepting new connections on SIGTERM, complete in-flight requests, close DB/Redis connections, then exit.
• Health endpoints — /health/live (is process alive?) and /health/ready (can it accept traffic?). Kubernetes uses these for restart and traffic routing decisions.
• Automatic restart — use PM2, Docker restart policies, or Kubernetes deployments to restart crashed processes automatically.
• Circuit breakers — prevent cascading failures when downstream services are degraded (opossum library).
• Timeouts everywhere — set timeouts on all outbound HTTP calls, DB queries, and cache operations. Never wait indefinitely.
• Idempotent retries — retry transient failures (network errors, 503s) with exponential backoff and jitter. Only retry idempotent operations.
• Bulkhead pattern — isolate critical paths. Use separate HTTP connection pools for critical and non-critical downstream calls so a slow dependency doesn’t exhaust your pool.
• Structured logging + alerting — log errors with request ID, user ID, and stack trace. Alert on error rate spikes, not individual errors.

// Retry with exponential backoff and jitter
async function withRetry(fn, maxRetries = 3) {
  for (let attempt = 1; attempt <= maxRetries; attempt++) {
    try { return await fn(); }
    catch (err) {
      if (attempt === maxRetries || !isTransient(err)) throw err;
      const delay = Math.min(1000 * 2 ** attempt + Math.random() * 100, 10000);
      await new Promise(r => setTimeout(r, delay));
    }
  }
}

Async AbortController / AbortSignal (global since Node.js 15, stable since Node 16) provide a standard mechanism for cancelling async operations — HTTP requests, stream pipelines, delays, and custom operations.

const { AbortController } = globalThis; // global since Node 16

// Cancel a fetch request after timeout
const controller = new AbortController();
const { signal } = controller;

// Auto-abort after 5 seconds
const timeoutId = setTimeout(() => controller.abort(new Error('Timeout')), 5000);

try {
  const response = await fetch('https://api.example.com/data', { signal });
  const data = await response.json();
  clearTimeout(timeoutId);
  return data;
} catch (err) {
  if (err.name === 'AbortError') console.log('Request timed out');
  else throw err;
}

// AbortSignal.timeout() — shorthand for auto-aborting (Node 17.3+)
const response = await fetch(url, { signal: AbortSignal.timeout(5000) });

// Cancel stream pipeline
const ac = new AbortController();
await pipeline(
  fs.createReadStream('input.txt'),
  transform,
  fs.createWriteStream('output.txt'),
  { signal: ac.signal }
);
// Cancel from another part of code: ac.abort();

// Custom cancellable operation
function delay(ms, signal) {
  return new Promise((resolve, reject) => {
    const id = setTimeout(resolve, ms);
    signal?.addEventListener('abort', () => {
      clearTimeout(id);
      reject(signal.reason || new Error('Aborted'));
    });
  });
}

Tooling Node.js 18.11+ introduced a built-in --watch flag that restarts the process automatically when a watched file changes — eliminating the need for nodemon in many development scenarios.

# Watch mode — restart on file changes
node --watch server.js

# Watch a specific directory or file
node --watch-path=./src --watch-path=./config server.js

# Available since Node 18.11 — stable since Node 20
# Node 22+ supports --watch for all built-in test runner too
node --watch --test tests/*.test.js

# Comparison:
# nodemon — feature-rich, configurable, mature, supports ext filtering
# --watch  — built-in, zero config, great for simple projects and CI

# nodemon still preferred for:
# - Watching specific file extensions: nodemon --ext ts,json
# - Running scripts before/after restart (nodemon events)
# - Non-JS files that trigger a restart
# - Delay before restarting: nodemon --delay 2

// Under the hood: --watch uses fs.watch() which uses OS-native
// inotify (Linux), FSEvents (macOS), or ReadDirectoryChangesW (Windows)
// for efficient file change detection without polling