The Node.js 24 Features Worth Changing Your Code For

Node 24's full changelog runs past sixty entries between the initial release and its LTS promotion, most of it internal, dependency bumps, or edge-case fixes that don't touch how application code gets written. Here's the subset that's actually worth knowing, filtered down from a changelog most developers reasonably skip reading in full.

TL;DR: Node.js 24's changes worth actually adopting: the permission model (--permission) reaching stability for sandboxing file/network access, require() supporting synchronous ESM imports in more cases (reducing CommonJS/ESM friction), further native TypeScript support improvements, and V8 engine updates that apply automatically with no code changes needed. Most of the sixty-plus changelog entries are internal or edge-case fixes that don't change day-to-day code.

The Permission Model Reaches Stability

node --permission --allow-fs-read="/app/data" --allow-net server.js

Node's experimental permission model, first introduced years earlier, stabilized in the Node 24 line, letting you run a script with explicit, enforced restrictions on filesystem access, network access, and child process spawning. A script started with --permission and without --allow-fs-write throws a runtime error the moment it attempts a write, rather than a script's actual capabilities being defined only by what the surrounding OS user account happens to allow.

// Check permissions at runtime, useful for a library that wants to
// behave differently when it detects restricted permissions
import { permission } from 'node:process';

if (!permission.has('fs.write')) {
  console.warn('Running with read-only filesystem access');
}

This matters most for anything running third-party or AI-generated code with reduced trust, a plugin system, a code execution sandbox, or a CI step running a dependency's install script. Previously, that isolation required a container or a separate OS user; Node's own permission model provides a lighter-weight boundary for cases where full container isolation is overkill.

require() and ESM Interop Gets Less Painful

// This now works directly in more cases without a dynamic import() workaround
const { someExport } = require('some-esm-only-package');

Node's require() gained broader support for synchronously loading ESM-only packages in CommonJS files across the Node 22-24 line, closing a long-standing friction point where a CommonJS project needing an ESM-only dependency had to reach for a top-level await import() or convert the whole file to ESM just to use one package. This doesn't apply universally, packages using genuinely async-only ESM features still need the dynamic import path, but the common case of a straightforward ESM package now interops directly.

Native TypeScript Support Continues Maturing

node src/index.ts   # runs directly, no ts-node/tsx, no build step

Building on the type-stripping support introduced in Node 22.6+ and stabilized further in 23.6, Node 24 continues refining native .ts execution, including better source-map support for stack traces pointing at the original TypeScript line rather than the stripped output. This is the feature with the most direct effect on daily workflow for any TypeScript project: running a script or CLI tool directly against .ts source without a compile step or a ts-node dependency, covered in more depth in the CLI tooling guide linked below.

What's in the Changelog but Not Worth Changing Code For

• V8 engine version bumps: newer JavaScript syntax support and JIT performance improvements apply automatically. No code change needed, no action required beyond upgrading.
• npm version bump bundled with Node: relevant if you rely on the bundled npm specifically, most projects using a separate package manager (pnpm, Yarn) aren't affected.
• Internal dependency updates (OpenSSL, ICU, etc.): security and correctness fixes that matter for the runtime's own safety, not something application code interacts with directly.
• Deprecation warnings for older APIs: worth noting if your codebase uses the specifically-flagged deprecated API, otherwise safe to ignore until the next major version actually removes it.

Checking Compatibility Before Upgrading

npx npm-check-updates --target minor  # check which deps have Node 24-tested versions
node --version                          # confirm the target version

Before upgrading a production app, check your dependencies' engines field for anything capping at an older Node major version, and run your full test suite against Node 24 in CI before merging the version bump. Most compatibility breaks in a Node major upgrade come from a native-module dependency (anything requiring node-gyp compilation) not yet supporting the new ABI, not from your own application code.

Conclusion

Reading a Node release's full changelog isn't necessary to stay current, most of what changes in any given major version is internal or transparent. The permission model reaching stability, the continued easing of CommonJS/ESM interop friction, and native TypeScript execution maturing further are the three changes in Node 24 actually worth adjusting a workflow around; the rest arrives automatically the moment you upgrade.

Related Guides

• Building a Node.js CLI tool
• Node.js 20 to 24 migration guide
• Node.js native TypeScript, no ts-node