TypeScript 5.9: import defer and What Actually Changed

TypeScript 5.9 shipped in Q1 2026 with the first genuinely new import primitive since dynamic import() landed years ago. The headline feature — import defer — lets you load a module without executing it, deferring evaluation until you actually access one of its exports. That sounds incremental. It isn’t. Pair that with --strictInference now defaulting on under --strict (it will break some code, and correctly so), smarter build caching, and a much-needed tsc --init cleanup, and 5.9 earns an upgrade on real codebases.

import defer: What It Is and What It Isn’t

The TC39 deferred imports proposal (Stage 3) is now supported in TypeScript 5.9. The idea is simple: you want a module’s type information available at compile time and the module graph loaded at startup — but you don’t want the module’s code to actually run until you use it.

Here’s the syntax:

import defer * as reportingTools from './reporting-tools';

// At startup: module is parsed, loaded, and ready — but NOT executed
// Startup stays fast even if reporting-tools pulls in heavy dependencies

export function generateReport(data: DataSet) {
  // Execution happens HERE, on first property access
  return reportingTools.buildPDF(data);
}

There are two hard constraints to know before you use it. First, only namespace imports are supported — no named or default imports:

// ERROR: named import not allowed with import defer
import defer { buildPDF } from './reporting-tools';

// ERROR: default import not allowed
import defer reportingTools from './reporting-tools';

// CORRECT: namespace import only
import defer * as reportingTools from './reporting-tools';

Second, import defer only works under --module preserve or --module esnext. TypeScript does not transform or downlevel the syntax — your runtime or bundler needs to handle it. Bundler support (Vite, Webpack, esbuild) is actively landing in 2026, but it isn’t universal yet. If your project targets CommonJS or an older module mode, this feature is on hold for you.

import defer vs dynamic import()

These are not the same thing. import() is asynchronous — you get a promise, you need await, it changes your function signature. import defer is synchronous and static. The module is resolved in the graph at load time, but it doesn’t execute until you touch it. For scenarios where you want predictable lazy loading without async complexity, import defer is the cleaner tool.

Good use cases: dashboard panels that load expensive charting libraries only when opened, CLI tools that defer help-text generators or rarely-used subcommands, backend services that load plugin systems only when a specific request requires them.

–strictInference Is On by Default Now

This is the change most likely to break your existing codebase on upgrade. With TypeScript 5.9, --strictInference is enabled automatically when "strict": true is set. Previously, TypeScript would silently fall back to unknown or a constraint type when generic inference was ambiguous. Now it reports an error and requires you to be explicit.

If you’re upgrading a large project and want to unblock the TypeScript version bump first, here’s your escape hatch:

{
  "compilerOptions": {
    "strict": true,
    "strictInference": false
  }
}

Set it to false temporarily, upgrade TypeScript, then address the inference errors package by package. The fix in most cases is straightforward: add explicit type arguments to ambiguous generic calls. This is the correct behavior — if TypeScript was guessing before, it was hiding bugs. The new errors are features.

–module node20 and a Saner tsc –init

--module nodenext has always been a floating target — it tracks the latest Node.js behavior and can shift under you between TypeScript versions. TypeScript 5.9 adds --module node20, which pins resolution to Node.js v20 semantics and implies --target es2023. For libraries shipping to Node.js LTS and CI pipelines that need predictability, this is a better default than nodenext.

tsc --init also got a long-overdue cleanup. The old output was 80+ lines of commented-out options that developers immediately deleted. The new output is minimal, with sensible modern defaults: "module": "nodenext", "target": "esnext", "jsx": "react-jsx", and both noUncheckedIndexedAccess and exactOptionalPropertyTypes enabled. It should have been this way years ago.

Build Performance: Real Numbers

TypeScript 5.9 delivers a 10–20% improvement in incremental compilation times, with smarter project reference caching cutting cold build times in monorepos. Type checking itself is 11% faster, which shows up as more responsive hover in VS Code and faster CI feedback. These aren’t headline numbers, but in a 200-package monorepo where every rebuild matters, they compound quickly.

Should You Upgrade?

Yes. The upgrade path is straightforward for most projects. The main thing to check is --strictInference: run tsc after upgrading and see what surfaces. Disable it temporarily if you need to ship, then fix incrementally. If you’re on Vite or a bundler that doesn’t yet support import defer natively, the feature is available but you won’t get bundler-level code splitting until support lands.

Start with npm install -D typescript@5.9, run your type checks, and treat any new errors as the type system doing its job. The official TypeScript 5.9 announcement and the full release notes are thorough and worth reading alongside your migration.