Node.js 22 LTS in 2026: Native TypeScript, Built-in SQLite & Every Feature That Matters

Node.js LTS releases used to be conservative — stability over features, with the interesting work happening in odd-numbered releases. Node.js 22 breaks that pattern. It ships native TypeScript execution, a built-in SQLite module, Web Streams stability, and the fastest V8 ever shipped in Node.js. It's the release that lets you delete tools from your stack, not add new ones.

This guide covers every production-relevant feature in Node.js 22 LTS — what it replaces, when to use it, and when to skip it in favor of battle-tested alternatives.

1. Native TypeScript: Run .ts Files Without a Build Step

Node.js 22 added --experimental-strip-types. It strips TypeScript type annotations at parse time (using OXC under the hood) and executes the result. This is not compilation — it's type erasure. No tsc, no ts-node, no tsx.

1. Native TypeScript: Run .ts Files Without a Build Step — what the listing was illustrating. Instead of copying a long snippet, treat the next few paragraphs as the contract you should enforce in review: what must be true for this to be safe, observable, and maintainable in 2026-era production.

The original example spanned roughly 1 substantive lines. Walk it mentally as a sequence: initialization, the happy path, then the failure surfaces (validation errors, network faults, partial writes). Cross-check the official release notes for your exact framework minor version—defaults and deprecations move faster than blog posts.

Translate to your codebase. Rename types, align with your router or ORM version, and wire the same invariants—idempotency keys where retries exist, structured logs with correlation IDs, and metrics that prove the path is actually exercised.

Opening line pattern (for orientation only): # Run TypeScript directly node --experimental-strip-types server.ts # With Node 22.6+ you can also use the shorter flag node --strip-types server.ts. Use your formatter, linter, and type checker to keep drift visible; do not rely on visually diffing pasted samples.

What it supports: type annotations, interfaces, enums (const enums only), type imports, generic syntax in function signatures.

What it does NOT support: decorators with emit, experimentalDecorators: true patterns, path aliases (tsconfig paths), or any TypeScript feature that requires code transformation rather than erasure.

When to use it: scripts, CLIs, one-off automation tools, dev utilities. Any file you'd have previously run with ts-node -e or tsx can now run with plain node --strip-types.

When to keep the build step: production servers. The build step (tsc + esbuild/swc) gives you type checking, path alias resolution, tree-shaking, and output optimization. --strip-types gives you none of that — it only skips the compilation step, not the type-checking step. Run tsc --noEmit separately in CI.

Same section, another listing: Use the same review checklist as above—policy, observability, failure handling, and version drift—this block only illustrated a different slice of the same workflow.

Teams ship faster when they separate mechanics from policy. Mechanics are API names and boilerplate; policy is who may call what, what gets logged, and what guarantees callers get. Cross-check the official release notes for your exact framework minor version—defaults and deprecations move faster than blog posts.

Re-implement the policy in your repo with your conventions—environment-based config, feature flags for risky paths, and tests that lock the behavior you care about. The old snippet is a sketch of mechanics, not a universal patch.

First concrete line in the removed listing looked like: // package.json { "scripts": { "dev": "node --strip-types --watch src/server.ts", "typecheck": "tsc --noEmit", "build": "tsc", "start": "node dist/server.js" } …. Verify that still matches your stack before you mirror the structure.

2. Built-in SQLite: Scripts Without Dependencies

Node.js 22.5+ ships node:sqlite — a synchronous SQLite interface built on SQLite 3.45. No native addons, no install step, no binary rebuilding after Node.js upgrades.

2. Built-in SQLite: Scripts Without Dependencies — what the listing was illustrating. Instead of copying a long snippet, treat the next few paragraphs as the contract you should enforce in review: what must be true for this to be safe, observable, and maintainable in 2026-era production.

Read this as a checklist, not a transcript. For each external dependency in the old example, ask: timeouts? retries with jitter? circuit breaking? What is the worst partial failure, and how would an operator detect it within minutes? Cross-check the official release notes for your exact framework minor version—defaults and deprecations move faster than blog posts.

Add integration coverage that hits the real adapter—not only mocks—at least on a smoke schedule. Mocks hide version skew between your code and the service you call.

Structural anchor from the removed code (abbreviated): import { DatabaseSync } from 'node:sqlite'; const db = new DatabaseSync(':memory:'); // In-memory, or pass a file path db.exec(` CREATE TABLE IF NOT EXISTS user….

Practical use cases: seed scripts, data migration scripts, local dev fixtures, CLI tools that need lightweight persistence, test fixtures with in-memory databases.

Not a replacement for: better-sqlite3 in production apps (it has more features, better TypeScript types, and is battle-tested), Prisma, or Drizzle ORM. For production SQLite workloads, better-sqlite3 or Drizzle remain the right choices.

3. The Built-in Watch Mode: Replace nodemon

Node.js 18 added --watch as experimental. Node.js 22 marks it stable. For most development workflows, you no longer need nodemon.

3. The Built-in Watch Mode: Replace nodemon — what the listing was illustrating. Instead of copying a long snippet, treat the next few paragraphs as the contract you should enforce in review: what must be true for this to be safe, observable, and maintainable in 2026-era production.

Production incidents rarely come from “unknown syntax”; they come from implicit assumptions baked into examples: small payloads, warm caches, single-region deployments, and friendly error payloads. Cross-check the official release notes for your exact framework minor version—defaults and deprecations move faster than blog posts.

Expand the narrative: document expected throughput, cardinality, and blast radius if this path misbehaves. Add dashboards that show error rate and latency percentiles, not just averages.

The listing began with: # Restart when any imported file changes node --watch src/server.js # Restart only when specific paths change node --watch --watch-path=src --watch-path=config …—use that as a mental bookmark while you re-create the flow with your modules and paths.

When nodemon is still better: when you need to watch non-imported files (e.g., restart when .env changes), when you need delay or exec configuration, or when your team already has a complex nodemon config. The built-in watch is simpler but less configurable.

4. Web Streams: Stable and Interoperable

The WHATWG Streams API (ReadableStream, WritableStream, TransformStream) is now fully stable in Node.js 22. This matters because edge runtimes (Cloudflare Workers, Vercel Edge, Deno Deploy) use Web Streams as their streaming primitive — code that uses Web Streams is runtime-portable.

4. Web Streams: Stable and Interoperable — what the listing was illustrating. Instead of copying a long snippet, treat the next few paragraphs as the contract you should enforce in review: what must be true for this to be safe, observable, and maintainable in 2026-era production.

Security and ergonomics move together. If the sample touched credentials, cookies, headers, or user input, re-validate against your org’s baseline: secret scanning, SSRF rules, SSR-safe patterns, and least-privilege IAM. Cross-check the official release notes for your exact framework minor version—defaults and deprecations move faster than blog posts.

Where the example used shorthand (“fetch user”, “save model”), spell out authorization checks and audit events you actually need for compliance.

Code lead-in was: import { ReadableStream, TransformStream } from 'node:stream/web'; // Create a ReadableStream that yields numbers const numberStream = new ReadableStream({ star….

Node.js built-in streams (stream.Readable) and Web Streams are now interoperable via Readable.fromWeb() and Readable.toWeb().

5. Improved Fetch and AbortController

Node.js 22 stabilizes the built-in fetch API (experimental since Node 18). You no longer need node-fetch or axios for basic HTTP requests in Node.js scripts.

5. Improved Fetch and AbortController — what the listing was illustrating. Instead of copying a long snippet, treat the next few paragraphs as the contract you should enforce in review: what must be true for this to be safe, observable, and maintainable in 2026-era production.

Performance work belongs in context. Note allocation patterns, N+1 queries, and accidental serialization hot loops. Cross-check the official release notes for your exact framework minor version—defaults and deprecations move faster than blog posts.

Profile with production-like data volumes; optimize the top frame, then re-measure. Caching should have explicit TTLs and invalidation stories—otherwise you debug “stale data” tickets for quarters.

Snippet started with: // Native fetch with timeout using AbortController async function fetchWithTimeout(url: string, timeoutMs = 5000) { const controller = new AbortController(); co….

6. ESM and CJS Interoperability Improvements

Node.js 22 adds require(ESM) support — you can now require() synchronous ES modules from CommonJS files. This was the biggest source of the "ESM package breaks my CJS app" problem.

6. ESM and CJS Interoperability Improvements — what the listing was illustrating. Instead of copying a long snippet, treat the next few paragraphs as the contract you should enforce in review: what must be true for this to be safe, observable, and maintainable in 2026-era production.

Testing strategy: one happy path, one permission-denied path, one dependency-down path, and one “absurd input” path. Cross-check the official release notes for your exact framework minor version—defaults and deprecations move faster than blog posts.

Property-based or fuzz tests help when parsers accept strings; snapshot tests help when output is structured HTML or JSON—use the right tool per boundary.

Removed listing began: // CommonJS file const { something } = require('./esm-module.mjs'); // Now works in Node 22 // Previously required: const { something } = await import('./esm-mo….

This doesn't solve every ESM interop issue, but it eliminates the most common pain point: CJS packages that can't consume pure-ESM libraries without restructuring their entire module system.

7. Performance: V8 12.4 and What It Means

Node.js 22 ships V8 12.4, which includes improvements to the Maglev compiler (V8's mid-tier JIT). Real-world benchmarks on typical web server workloads show 10-15% throughput improvement over Node.js 20 LTS without any code changes.

What specifically improved: string operations, JSON parsing/serialization, array methods on large arrays, and startup time for scripts. If your Node.js app does heavy JSON processing (API proxy, data transformation), the V8 upgrade alone justifies the LTS upgrade.

Frequently Asked Questions

Should I upgrade from Node.js 20 LTS to 22 LTS now?
Yes, if you're starting a new project or can test your dependencies. Node.js 20 enters maintenance-only support in April 2026 and goes end-of-life in April 2026. Node.js 22 LTS is active until April 2027. The migration is low-risk for most apps — run your test suite, check your native addons for compatibility, upgrade.

Is --strip-types production-safe?
For execution, yes — it's just erasure. But "production-safe" depends on your definition. It skips type checking, so you need tsc --noEmit in your CI pipeline separately. For the actual server process, compile to JavaScript with tsc or esbuild for better startup time and more predictable behavior.

Does the built-in SQLite support WAL mode and concurrent reads?
Yes — PRAGMA journal_mode = WAL works. But the built-in module is synchronous only (no async API), which blocks the event loop during queries. For write-heavy or high-concurrency SQLite use cases, better-sqlite3 (which is also synchronous but more optimized) or Drizzle ORM with better-sqlite3 remain better choices.

Does Node.js 22 native fetch replace axios?
For simple GET/POST requests: yes. For production API clients that need request interceptors, automatic retry, request/response transformation, or instance-based configuration: axios or ky are still more ergonomic. The native fetch API is complete but low-level.

What happened to the Node.js permission model?
The permission model (--experimental-permission) is still experimental in Node.js 22 but more complete. It lets you restrict file system, network, and child process access at the Node.js level — useful for running untrusted scripts in a sandboxed environment. Not production-stable enough to recommend for most use cases yet.

Can I use top-level await in Node.js 22 without ESM?
No — top-level await requires ESM. You need either .mjs extension, "type": "module" in package.json, or TypeScript with "module": "NodeNext" in tsconfig. CommonJS files must use async functions or .then() chains.

Conclusion

Node.js 22 LTS is the most practically useful LTS release since Node.js 16 brought ES modules to stable. The native TypeScript execution removes an entire category of dev tooling for scripts. The built-in SQLite removes a native addon dependency for lightweight persistence. The watch mode removes nodemon for straightforward dev workflows. The V8 upgrade improves performance for free.

The pattern across all these features is the same: Node.js is absorbing tools that previously required separate packages, converging on a more complete runtime that needs less ceremony to get started with.

If you're building Node.js services and want engineers who stay current on the runtime, not just the frameworks, Softaims pre-vetted Node.js developers are assessed on platform knowledge, not just API familiarity.