Typescript V6

TypeScript 6 Skill

Build, configure, and debug TypeScript 6+ projects with precise compiler guidance and modern module/runtime patterns.

Before You Start

This skill is for real TypeScript 6+ project work: daily development, configuration, debugging, and upgrades.

Known Issues This Skill Prevents

1. Surprise build failures from missing types entries after upgrading 2. Unexpected dist/src/... output because rootDir was never explicit 3. Deprecated moduleResolution node or baseUrl settings surviving into a TS 6 migration 4. Confusion about when to use bundler vs nodenext 5. Overusing ignoreDeprecations: "6.0" as a long-term fix instead of a temporary migration aid 6. Misunderstanding --stableTypeOrdering as a production performance flag instead of a TS 6→7 comparison tool 7. Missing Node/test globals because TS 6+ projects often need explicit types entries 8. New side-effect import errors because TS 6 applies stricter side-effect import checking

Quick Start

Step 1: Make the important options explicit

{
  "compilerOptions": {
    "rootDir": "./src",
    "outDir": "./dist",
    "types": ["node"],
    "strict": true
  },
  "include": ["src/**/*"]
}

Why this matters: TypeScript 6 changed enough defaults and behaviors that explicit configuration now matters more in everyday work. rootDir and types are two of the most important settings to keep intentional.

Step 2: Pick module resolution deliberately

{
  "compilerOptions": {
    "module": "esnext",
    "moduleResolution": "bundler"
  }
}

Why this matters: TypeScript 6 deprecates moduleResolution: "node"/"node10". Bundled apps should usually choose bundler, while Node.js packages should usually choose nodenext.

Step 3: Use TS 6-era library typings only when the target/lib/runtime really supports them

const escaped = RegExp.escape('(hello)');

const value = new Map<string, number>().getOrInsert('count', 0);

const tomorrow = Temporal.Now.instant().add({ hours: 24 });

Why this matters: TypeScript 6 can type new platform APIs before every runtime ships them. Distinguish compiler types available from runtime support available.

Step 4: Verify config and resolution before changing code

npx tsc --noEmit
npx tsc --showConfig
npx tsc --explainFiles

Why this matters: TS 6+ projects often fail because the effective config or included file graph is not what the project expects. Validate that first, then refactor.

Critical Rules

Always Do

• Make rootDir explicit when your sources are nested below the tsconfig.json
• Make the types array explicit for Node, test runners, Workers, Bun, or other global type providers when the project relies on those ambient globals
• Prefer moduleResolution: "bundler" for bundled web apps and moduleResolution: "nodenext" for modern Node.js packages
• Treat ignoreDeprecations: "6.0" as a short-term migration escape hatch, not the destination
• Use paths directly instead of relying on deprecated baseUrl
• Make types explicit when the project truly depends on Node, test, Worker, or Bun globals
• Treat side-effect imports as intentionally checked and fix their paths deliberately
• Verify runtime support before recommending Temporal, getOrInsert, or RegExp.escape
• Use --stableTypeOrdering only when comparing TS 6 and TS 7 behavior or investigating ordering-sensitive issues
• Use satisfies, exhaustive never checks, and assertion functions when TS 6+ code exposes type ambiguity that should be made explicit
• Re-run tsc --noEmit after config changes and again after type-pattern refactors

Never Do

• Never recommend deprecated moduleResolution: "node" / "node10" as the forward-looking path
• Never recommend removed moduleResolution: "classic" as a fallback path
• Never leave types implicit if a project depends on @types/node, test globals, or platform globals
• Never assume ignoreDeprecations: "6.0" will keep working in TypeScript 7
• Never present TS 7 preview context as if it were already the default compiler runtime
• Never imply that TypeScript types guarantee runtime availability for new ECMAScript APIs
• Never import pre-TS 6 tsconfig advice that still uses skipDefaultLibCheck, downlevelIteration, or old AMD/UMD/SystemJS examples

Common Mistakes

Wrong - relying on pre-TS 6 ambient type loading:

{
  "compilerOptions": {
    "outDir": "./dist"
  }
}

Correct - declare what global types the project actually needs:

{
  "compilerOptions": {
    "outDir": "./dist",
    "types": ["node"]
  }
}

Why: In TS 6+, explicit types improves performance and predictability when the project depends on ambient globals.

Wrong - keep deprecated path alias setup unchanged:

{
  "compilerOptions": {
    "baseUrl": "./src",
    "paths": {
      "@app/*": ["app/*"]
    }
  }
}

Correct - inline the source prefix in `paths`:

{
  "compilerOptions": {
    "paths": {
      "@app/*": ["./src/app/*"]
    }
  }
}

Why: baseUrl is deprecated in TS 6. The forward-looking setup is direct paths entries.

Wrong - type widening hides the real config contract:

const compilerMode = {
  moduleResolution: 'bundler',
  strict: true,
};

Correct - keep literals checked without widening:

const compilerMode = {
  moduleResolution: 'bundler',
  strict: true,
} satisfies {
  moduleResolution: 'bundler' | 'nodenext';
  strict: boolean;
};

Why: satisfies is not new in TS 6, but it is one of the cleanest ways to make config and option objects precise without losing inference.

Wrong - union handling silently misses a new case:

type ResolutionMode = 'bundler' | 'nodenext' | 'preserve';

function describeMode(mode: ResolutionMode) {
  if (mode === 'bundler') return 'bundled app';
  return 'node-style runtime';
}

Correct - exhaustive union handling:

type ResolutionMode = 'bundler' | 'nodenext' | 'preserve';

function describeMode(mode: ResolutionMode) {
  switch (mode) {
    case 'bundler':
      return 'bundled app';
    case 'nodenext':
      return 'node-style runtime';
    case 'preserve':
      return 'mixed emit strategy';
    default: {
      const exhaustive: never = mode;
      return exhaustive;
    }
  }
}

Why: TypeScript 6+ projects often rely on unions for config, platform, and runtime state. Exhaustive never checks make missing cases obvious.

Wrong - use `stableTypeOrdering` as a normal build flag:

tsc --stableTypeOrdering --build

Correct - use it only for comparison/debugging:

tsc --noEmit --stableTypeOrdering

Why: The flag exists to reduce TS 6 vs TS 7 output noise. It can meaningfully slow type-checking and is not intended as a permanent default.

Known Issues Prevention

Bundled Resources

References

• Dedicated TS 6 migration guide → `references/migration-v6-reference.md`
• Defaults and configuration behavior → `references/defaults-migration-reference.md`
• Deprecations and replacements → `references/deprecations-reference.md`
• Module resolution and `#/` imports → `references/module-resolution-imports-reference.md`
• New library types and APIs → `references/stdlib-types-reference.md`
• Verification workflow and diagnostics → `references/workflow-diagnostics-reference.md`
• Type-safe patterns for TS 6+ code → `references/type-patterns-reference.md`
• `stableTypeOrdering` and TS 7 context → `references/stable-ordering-ts7-reference.md`
• Reference index → `references/README.md`

Configuration Reference

Bundled application baseline

{
  "compilerOptions": {
    "target": "es2025",
    "module": "esnext",
    "moduleResolution": "bundler",
    "lib": ["es2025", "dom"],
    "rootDir": "./src",
    "outDir": "./dist",
    "strict": true,
    "noUncheckedSideEffectImports": true
  },
  "include": ["src/**/*"]
}

Key settings:

• rootDir: Prevents accidental dist/src/... nesting
• types: Add it explicitly only when the project actually depends on Node/test/platform globals
• moduleResolution: "bundler": Best fit for Vite/esbuild/Rollup/Webpack-style app builds
• target: "es2025" / lib: ["es2025", ...]: Gives access to TS 6-era built-in types such as RegExp.escape

Node package baseline

{
  "compilerOptions": {
    "target": "es2022",
    "module": "nodenext",
    "moduleResolution": "nodenext",
    "lib": ["es2022"],
    "rootDir": "./src",
    "outDir": "./dist",
    "types": ["node"],
    "strict": true
  },
  "include": ["src/**/*"]
}

Key settings:

• nodenext: Use when the package's runtime semantics should follow modern Node.js ESM/CJS rules
• Explicit .js import specifiers and package.json module settings still matter; TS 6 does not remove that responsibility

Project Structure

my-ts-project/
├── src/
├── dist/
├── package.json
└── tsconfig.json

Why this matters: TS 6 rewards explicit, boring project structure. Most upgrade pain comes from old implicit config behavior, not from source code syntax.

Common Patterns

Direct paths migration

{
  "compilerOptions": {
    "paths": {
      "@/*": ["./src/*"]
    }
  }
}

Use this instead of keeping deprecated baseUrl around.

#/ subpath imports for package-internal aliases

{
  "name": "my-package",
  "type": "module",
  "imports": {
    "#/*": "./dist/*"
  }
}

import * as utils from '#/utils.js';

Use this when your package/runtime already supports Node's imports field and you want package-native aliases instead of bundler-only conventions. Keep the exact mapping aligned with the files the package actually ships.

Temporary migration shield

{
  "compilerOptions": {
    "ignoreDeprecations": "6.0"
  }
}

Use this only long enough to unblock the migration. Plan to remove it before TS 7.

Monorepo/project-reference check

{
  "compilerOptions": {
    "composite": true,
    "declaration": true,
    "isolatedDeclarations": true,
    "rootDir": "./src",
    "outDir": "./dist"
  }
}

Use this when packages emit .d.ts files or participate in project references. isolatedDeclarations is not TS 6-exclusive, but it fits the stricter, more explicit TS 6+ workflow well.

Verification Workflow

npx tsc --noEmit
npx tsc --showConfig
npx tsc --explainFiles
npx tsc --traceResolution

When to use each command:

• --noEmit: First-pass health check after config or type changes
• --showConfig: Confirm the effective merged config before debugging phantom settings
• --explainFiles: Understand why a file is in the program or why a file graph changed
• --traceResolution: Debug paths, package exports, types, or #/ import resolution

Troubleshooting

"Cannot find name 'process'" / "Cannot find name 'describe'"

Add the appropriate types entries and install the matching @types/* package if needed.

Output path changed unexpectedly

Set rootDir explicitly. This is one of the most common TS 6 upgrade regressions.

Deprecated option warnings keep appearing

Migrate away from deprecated settings; use ignoreDeprecations: "6.0" only while the real replacement work is still in progress.

New side-effect import errors appear in TS 6+

Inspect the import path and whether the file is intended as a side-effect-only module. TS 6 applies stricter checking here, so old typos or vague side-effect imports can surface now.

RegExp.escape / Temporal / getOrInsert compile but fail in production

Check runtime support. TS 6 can expose types before every target environment implements the runtime API.

Setup Checklist

• [ ] rootDir is explicit if source files live below the tsconfig.json
• [ ] types is explicit for Node, tests, Workers, Bun, or other ambient platforms
• [ ] moduleResolution is bundler or nodenext, not deprecated node / node10
• [ ] Removed classic resolution, skipDefaultLibCheck, and downlevelIteration are not lingering in copied config
• [ ] Deprecated baseUrl / downlevelIteration / ES5-era settings are removed or scheduled for removal
• [ ] tsc --showConfig and tsc --explainFiles were used if the upgrade behavior is still surprising
• [ ] ignoreDeprecations: "6.0" is temporary and tracked
• [ ] New TS 6 APIs are validated against actual runtime support
• [ ] --stableTypeOrdering is only used for migration comparisons, not normal builds

Official Documentation

• TypeScript 6.0 Release Notes
• TypeScript Handbook
• TSConfig Reference
• Compiler Options Reference
• Choosing Compiler Options

TypeScript 6 Skill

Build and operate TypeScript 6+ projects with modern tsconfig patterns, compiler diagnostics, and release-note-grounded guidance.

What This Skill Does

Provides expert assistance for TypeScript 6+ development and configuration work. It focuses on the compiler changes and workflows that most often break or confuse real projects: explicit types, explicit rootDir, deprecated resolution/module settings, #/ imports, newer ES library typings surfaced in TS 6, and the TS 6→TS 7 bridge tools such as ignoreDeprecations and stableTypeOrdering. It also includes practical compiler-verification workflow and TS-safe type-pattern guidance that fit TypeScript 6+ projects without pretending older generic advice is TS 6-specific.

Core Capabilities

• Configure tsconfig.json intentionally for TypeScript 6+ projects
• Choose between bundler and nodenext module-resolution strategies without falling back to deprecated node / node10
• Fix common regressions caused by types and rootDir changes
• Migrate deprecated baseUrl, ES5-era targets, and legacy module settings to forward-looking replacements
• Explain and apply TypeScript 6-era library typings and patterns such as #/ subpath imports, RegExp.escape, Temporal, and Map.getOrInsert
• Use compiler diagnostics like --showConfig, --explainFiles, and --traceResolution before changing source code blindly
• Apply TS-safe patterns such as satisfies, exhaustive unions, and assertion functions when the codebase reveals type ambiguity
• Use --stableTypeOrdering and TS 7 preview context responsibly during migration work

Auto-Trigger Keywords

Primary Keywords

• typescript 6
• ts 6
• ignoreDeprecations
• stableTypeOrdering
• types array
• noUncheckedSideEffectImports
• moduleResolution node is deprecated
• baseUrl is deprecated
• tsc --showConfig
• tsc --traceResolution
• tsc --explainFiles

Secondary Keywords

• subpath imports
• #/ imports
• RegExp.escape
• Temporal API
• getOrInsert
• baseUrl migration
• downlevelIteration
• es2025

Error-Based Keywords

• "Cannot find name 'process'"
• "Cannot find name 'describe'"
• "moduleResolution node is deprecated"
• "output is going to dist/src"
• "baseUrl is deprecated"
• "stableTypeOrdering"

Known Issues Prevention

When to Use

Use This Skill For

• Building or maintaining a TypeScript 6+ codebase
• Fixing tsconfig.json in an active TypeScript 6+ project
• Choosing modern module resolution for bundlers or Node.js
• Migrating deprecated options such as baseUrl and moduleResolution: "node"
• Adopting TS 6-era standard-library types and platform APIs

Don't Use This Skill For

• Generic TypeScript language tutoring unrelated to TS 6 changes
• Framework-specific runtime behavior that belongs to Next.js, Vite, Tauri, etc.
• TypeScript compiler API migration work for TS 7-native internals beyond high-level context

Version Policy

[!NOTE]

This skill targets TypeScript 6+ with special attention to the TypeScript 6.0 default/deprecation changes. It includes TS 7 context only as comparison guidance, not as the primary implementation target. When exact feature timing or runtime availability matters, verify it against the official release notes and TSConfig docs.

Quick Usage

# Check the current project with an explicit TS 6 compiler
npx tsc --noEmit

# Compare type ordering behavior for TS 6 vs TS 7 migration work
npx tsc --noEmit --stableTypeOrdering

# Temporary migration shield while you remove deprecated options
# (do not keep this forever)
# "ignoreDeprecations": "6.0"

Token Efficiency

Reference Documentation

For deeper guidance on the most failure-prone areas, see:

See the References Index for navigation.

File Structure

typescript-v6/
├── SKILL.md                              # Quick-start patterns, critical rules, and upgrade guidance
├── README.md                             # This file - discovery and quick reference
└── references/
    ├── README.md                         # Reference index
    ├── migration-v6-reference.md         # Dedicated TypeScript 6 migration guide
    ├── defaults-migration-reference.md   # TS 6+ defaults and configuration behavior
    ├── deprecations-reference.md         # Deprecated options and replacements
    ├── module-resolution-imports-reference.md # bundler/nodenext and `#/` imports
    ├── stdlib-types-reference.md         # New platform/library types in TS 6
    ├── workflow-diagnostics-reference.md # Compiler commands for migration debugging
    ├── type-patterns-reference.md        # TS-safe patterns for TS 6+ code
    └── stable-ordering-ts7-reference.md  # `stableTypeOrdering` and TS 7 context

Dependencies

Official Documentation

• TypeScript 6.0 Release Notes
• TypeScript Docs
• TSConfig Reference
• Compiler Options Reference
• Choosing Compiler Options

Related Skills

• vite-v8 - Useful when TypeScript 6 config changes live inside a Vite 8 project
• vitest-v4 - Useful when TS 6 upgrades affect test globals, coverage config, or vitest.config.ts
• github-actions - CI workflow updates when tsc --noEmit or migration checks run in GitHub Actions

---

License: MIT

TypeScript 6 Defaults and Configuration Reference

TypeScript 6 changed enough compiler behavior that several assumptions that used to stay implicit often need to become explicit in real projects.

Highest-Impact Upgrade Checks

1. Make types explicit

If a project depends on Node.js globals, a test runner, Workers, or Bun globals, add the exact type packages it needs instead of relying on ambient discovery.

{
  "compilerOptions": {
    "types": ["node", "jest"]
  }
}

This improves both performance and predictability compared with older "load everything from @types" assumptions.

1b. Expect side-effect import checking to be stricter

TS 6 applies stricter checking to side-effect-only imports, so previously ignored path mistakes can start surfacing during normal project work.

2. Make rootDir explicit

If the source tree lives under src/, TypeScript 6+ projects often need this:

{
  "compilerOptions": {
    "rootDir": "./src",
    "outDir": "./dist"
  },
  "include": ["src/**/*"]
}

Without it, some projects can see emitted files shift from dist/index.js to dist/src/index.js.

3. Keep strict deliberate

If the project already uses strict mode, keep it explicit. If the repo truly needs looser semantics during a staged migration, say so explicitly instead of assuming older defaults.

{
  "compilerOptions": {
    "strict": false
  }
}

4. Keep target / lib intentional

Use modern library types only when the project can support them.

{
  "compilerOptions": {
    "target": "es2025",
    "lib": ["es2025", "dom"]
  }
}

Migration Baselines

Bundled web app

{
  "compilerOptions": {
    "target": "es2025",
    "module": "esnext",
    "moduleResolution": "bundler",
    "lib": ["es2025", "dom"],
    "rootDir": "./src",
    "outDir": "./dist",
    "strict": true
  },
  "include": ["src/**/*"]
}

Add a types array here only if the app or its tooling actually needs Node/test/platform globals.

Node package

{
  "compilerOptions": {
    "target": "es2022",
    "module": "nodenext",
    "moduleResolution": "nodenext",
    "lib": ["es2022"],
    "rootDir": "./src",
    "outDir": "./dist",
    "types": ["node"],
    "strict": true
  },
  "include": ["src/**/*"]
}

5. Prefer compiler-state inspection before guessing

npx tsc --showConfig
npx tsc --explainFiles

When project behavior looks strange, inspect the effective config and file graph before rewriting source code.

Temporary Escape Hatch

{
  "compilerOptions": {
    "ignoreDeprecations": "6.0"
  }
}

Use this only to buy time while you remove deprecated settings. Do not treat it as a permanent upgrade strategy.

TypeScript 6 Deprecations Reference

TypeScript 6 keeps compatibility pressure high so TS 7 does not need to carry legacy configuration forever.

Deprecated Options You Should Act On

baseUrl Migration

// Before
{
  "compilerOptions": {
    "baseUrl": "./src",
    "paths": {
      "@app/*": ["app/*"]
    }
  }
}

// After
{
  "compilerOptions": {
    "paths": {
      "@app/*": ["./src/app/*"]
    }
  }
}

ignoreDeprecations Guidance

{
  "compilerOptions": {
    "ignoreDeprecations": "6.0"
  }
}

Use this when the migration has multiple moving pieces and you need a short window to replace deprecated settings. Remove it before the repo treats TS 6 as "done".

Recommended Strategy

1. Make types and rootDir explicit first 2. Replace deprecated resolution/module settings next 3. Remove baseUrl and other legacy options 4. Keep ignoreDeprecations: "6.0" only until the new config is stable

TypeScript 6 Migration Reference

Use this reference when a project is moving from TypeScript 5.x-era assumptions into TypeScript 6 behavior.

High-Impact Migration Changes

1. Re-check ambient globals

Projects that rely on Node.js, test, Worker, or Bun globals should make types explicit instead of relying on broad ambient discovery.

{
  "compilerOptions": {
    "types": ["node", "jest"]
  }
}

2. Make rootDir explicit

{
  "compilerOptions": {
    "rootDir": "./src",
    "outDir": "./dist"
  },
  "include": ["src/**/*"]
}

This avoids surprising emit-path shifts such as dist/src/....

3. Replace deprecated config early

Look for old settings like:

• moduleResolution: "node" / "node10"
• baseUrl
• downlevelIteration
• target: "es5"

Move to bundler or nodenext, direct paths, and more modern targets first.

4. Use the compiler before editing code

npx tsc --noEmit
npx tsc --showConfig
npx tsc --explainFiles
npx tsc --traceResolution

These commands usually explain the upgrade faster than rewriting source files blindly.

5. Keep ignoreDeprecations temporary

{
  "compilerOptions": {
    "ignoreDeprecations": "6.0"
  }
}

Use it to create breathing room, then remove it once the real replacements land.

Migration Checklist

• [ ] rootDir is explicit if sources live below the tsconfig.json
• [ ] types is explicit where ambient globals matter
• [ ] moduleResolution is bundler or nodenext
• [ ] deprecated options are removed or scheduled for removal
• [ ] tsc --showConfig and tsc --explainFiles were used if behavior is still surprising
• [ ] runtime support for Temporal, RegExp.escape, and Map.getOrInsert* was checked separately

Quick Reference

TypeScript 6 Module Resolution and Imports Reference

The most important TypeScript 6 module-resolution decision is whether the project is primarily a bundled app or a Node.js package/runtime.

Choose bundler for bundled apps

{
  "compilerOptions": {
    "module": "esnext",
    "moduleResolution": "bundler"
  }
}

Use this for Vite, Rollup, esbuild, Webpack, and similar build-driven applications.

Choose nodenext for modern Node.js packages

{
  "compilerOptions": {
    "module": "nodenext",
    "moduleResolution": "nodenext"
  }
}

Use this when package exports, ESM/CJS interop, and Node's native resolver should define behavior.

#/ Subpath Imports

TypeScript 6 supports Node's #/-style subpath imports under bundler and nodenext resolution modes.

{
  "name": "my-package",
  "type": "module",
  "imports": {
    "#/*": "./dist/*"
  }
}

import * as utils from '#/utils.js';

This example is a package/runtime alignment pattern, not a generic source-alias recipe. The mapping should reflect the files the package actually ships and resolves at runtime.

Alias Decision Heuristic

• Use paths when you need TypeScript/build-tool aliasing inside a project
• Use package imports with #/ when you want a Node-native, package-internal alias strategy
• Do not mix strategies casually; keep runtime and compiler expectations aligned

Common Failure Mode

If #/ imports compile but fail at runtime, the runtime or package metadata likely does not actually support the same alias behavior yet, or the mapping does not match the files the package ships.

TypeScript 6 Skill References

Use these references when the main SKILL.md is not enough:

Suggested Reading Order

• Upgrading an existing repo? Start with migration-v6-reference.md
• Need the broader TS 6+ config behavior? Then read defaults-migration-reference.md
• Removing warnings or legacy config? Start with deprecations-reference.md
• Choosing between `bundler`, `nodenext`, or `#/` imports? Start with module-resolution-imports-reference.md
• Trying new TS 6 library APIs? Start with stdlib-types-reference.md
• Debugging config/file inclusion/resolution? Start with workflow-diagnostics-reference.md
• Need safer type patterns in TS 6+ code? Start with type-patterns-reference.md
• Comparing TS 6 and TS 7 behavior? Start with stable-ordering-ts7-reference.md

Official Sources

• TypeScript 6.0 Release Notes
• TypeScript Docs
• TSConfig Reference

TypeScript 6 stableTypeOrdering and TS 7 Context Reference

TypeScript 6 is partly a bridge release toward TypeScript 7. One of the migration tools added in TS 6 is --stableTypeOrdering.

What --stableTypeOrdering Is For

npx tsc --noEmit --stableTypeOrdering

Use it when:

• comparing TS 6 and TS 7 behavior
• reducing noisy declaration-output diffs during migration work
• investigating type-order-sensitive inference changes

What It Is Not For

• normal development builds
• CI defaults for everyday projects
• performance tuning

It can add noticeable type-checking overhead.

If It Reveals New Errors

That usually means previous inference depended on unstable ordering. The fix is usually to make intent explicit.

// Prefer explicit annotations when inference starts to wobble
const config: SomeExplicitType = buildConfig();
someFunction<SomeExplicitType>(config);

TS 7 Context

Keep TS 7 context high-level in TS 6 work:

• TS 6 is the practical migration surface today
• TS 7 context matters because TS 6 deprecations are preparing for that future
• Do not treat TS 7 preview behavior as the default answer unless the user explicitly targets it

TypeScript 6 Standard Library Types Reference

TypeScript 6 adds or promotes several useful standard-library types. The compiler can understand them before every runtime ships them, so verify runtime support separately.

es2025

{
  "compilerOptions": {
    "target": "es2025",
    "lib": ["es2025", "dom"]
  }
}

This gives access to TS 6-era built-in types such as RegExp.escape and other APIs moved from esnext into es2025.

RegExp.escape

function buildWordMatcher(word: string) {
  const escaped = RegExp.escape(word);
  return new RegExp(`\\b${escaped}\\b`, 'g');
}

Use this instead of hand-rolled regex escaping.

Temporal

Use Temporal with esnext/esnext.temporal typing support when the environment and project actually intend to adopt it.

const tomorrow = Temporal.Now.instant().add({ hours: 24 });

Map.getOrInsert / getOrInsertComputed

const counts = new Map<string, number>();

counts.getOrInsert('retries', 0);
counts.getOrInsertComputed('cache-key', () => expensiveDefault());

These are nice ergonomics wins, but they are still subject to runtime support constraints.

DOM Iterables Simplification

TypeScript 6 folds iterable DOM support into dom, so modern browser-focused projects often no longer need a separate dom.iterable entry.

TypeScript 6+ Type Patterns Reference

These patterns are not new in TS 6, but they are especially useful in TypeScript 6+ projects when the codebase exposes unclear contracts, widened literals, or incomplete unions.

satisfies for Config and Option Objects

const compilerMode = {
  moduleResolution: 'bundler',
  strict: true,
} satisfies {
  moduleResolution: 'bundler' | 'nodenext';
  strict: boolean;
};

Use this when you want validation without widening away the useful literal types.

Exhaustive Union Handling

type ResolutionMode = 'bundler' | 'nodenext' | 'preserve';

function describeMode(mode: ResolutionMode) {
  switch (mode) {
    case 'bundler':
      return 'bundled app';
    case 'nodenext':
      return 'node-style runtime';
    case 'preserve':
      return 'mixed emit strategy';
    default: {
      const exhaustive: never = mode;
      return exhaustive;
    }
  }
}

Use this when config, runtime, or state unions change and you need the compiler to prove coverage.

Assertion Functions

function assertNodeTypes(types: string[] | undefined): asserts types is string[] {
  if (!types || !types.includes('node')) {
    throw new Error('Expected Node types to be configured');
  }
}

Use assertion functions when migration checks need to narrow unknown or optional data from config readers, CLI inputs, or JSON loading.

Branded IDs and Nominal Separation

type Brand<T, B extends string> = T & { readonly __brand: B };
type PackageName = Brand<string, 'PackageName'>;

This is useful when migration tooling or repo scripts pass around multiple plain strings that should not be mixed up.

Result Pattern for Type-Safe Operations

type Result<T, E = Error> =
  | { success: true; value: T }
  | { success: false; error: E };

Use this when upgrade helpers or config loaders need explicit success/error control flow instead of exceptions.

Quick Reference

TypeScript 6 Workflow and Diagnostics Reference

Verify the compiler state early and often. In TypeScript 6+, that matters more than guessing at source-level fixes.

Recommended Verification Loop

1. Check health before editing

npx tsc --noEmit

Use this as the first pass after a version bump, config rewrite, or unexplained compiler failure.

2. Confirm the real merged config

npx tsc --showConfig

Use this when the file says one thing but the compiler behaves like another. It is especially useful when extends chains or workspace-level config are involved.

3. See why a file is included

npx tsc --explainFiles

Use this to diagnose:

• unexpected dist/src/... emit roots
• test files or config files leaking into production builds
• monorepo package boundaries that are wider than expected

4. Trace module and type resolution

npx tsc --traceResolution

Use this when debugging:

• paths aliases
• types package discovery
• package.json exports / imports
• #/ subpath imports under bundler or nodenext

Agent-Safe Workflow

1. update config 2. run npx tsc --noEmit 3. if config still feels wrong, run --showConfig 4. if file inclusion still feels wrong, run --explainFiles 5. if import/type resolution still feels wrong, run --traceResolution 6. only then refactor source types or runtime code

Monorepo / Project References

For package-based repos, make the emitting packages explicit.

{
  "compilerOptions": {
    "composite": true,
    "declaration": true,
    "isolatedDeclarations": true,
    "rootDir": "./src",
    "outDir": "./dist"
  }
}

composite and declaration are not new in TS 6, but they pair well with TS 6's push toward more explicit config and faster incremental tooling.

Quick Reference