Skip to main content
Version: Next

Using TypeScript 7

TypeScript 7.0 ships a native tsc, but it does not ship the JavaScript compiler API that ts-jest needs for transforms, language-service diagnostics, source maps, hoisting, and custom AST transformers. Microsoft provides @typescript/typescript6 for tools that still need that API and recommends installing it alongside TypeScript 7 with npm aliases.

Installation​

Install the two compilers under separate package names:

npm install --save-dev '@typescript/native@npm:typescript@^7.0.2' 'typescript@npm:@typescript/typescript6@^6.0.2'

If npm reports ERESOLVE after replacing typescript with TypeScript 7 directly, do not bypass the peer dependency check with --legacy-peer-deps. Use the aliases above instead: the native package does not provide the compiler API required by ts-jest, while the typescript alias does.

The equivalent package.json configuration is:

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}

With this layout:

  • npx tsc runs the native TypeScript 7 compiler for project type-checking and builds.
  • npx tsc6 runs the TypeScript 6 compatibility compiler when you need to compare results.
  • ts-jest imports typescript, so it receives the supported TypeScript 6 JavaScript API.

Do not set the ts-jest compiler option to @typescript/native. TypeScript 7.0 has no compatible JavaScript API, and ts-jest will stop early with an actionable configuration error if that package is loaded directly.

Why ts-jest uses the compatibility API​

Calling TypeScript 7 internals or translating between its native protocol and the TypeScript 6 API would create an unstable second compiler integration. It would also leave gaps in custom transformers and Program access. The side-by-side layout is the upstream-supported transition path and keeps one established API on the Jest transform path.

Two alternatives were deliberately rejected:

  • ts-jest does not silently fall back to @typescript/typescript6 when typescript resolves to TypeScript 7. ts-jest's public declarations import classic compiler types from typescript; a runtime-only fallback would make those declarations inconsistent with the package the user's type checker resolves.
  • ts-jest does not call unstable native APIs or combine TypeScript 7 diagnostics with TypeScript 6 transforms. TypeScript 7.0 has no stable programmatic API, and a dual-compiler path would not preserve the existing transformer and Program contract.

This has two practical tradeoffs:

  • TypeScript 7's native performance applies to tsc, not to transforms performed by ts-jest. Jest transform performance is the same as TypeScript 6.
  • TypeScript 7 should be the authoritative project type-check. Diagnostics produced during Jest transforms come from the TypeScript 6 compatibility API and can differ from TypeScript 7. Run npx tsc --noEmit separately in local development and CI.

TypeScript 6 reports TS5107 for moduleResolution: Node10. ts-jest filters that diagnostic only when it supplied Node10 as its own historical default. If your tsconfig explicitly selects Node10, TS5107 is preserved so that you can migrate the project configuration. Other TypeScript deprecations are not suppressed.

Backward compatibility​

Projects using TypeScript 4.3 through 6 continue to install typescript normally and require no configuration changes. The typescript alias above exposes version 6, so it also satisfies ts-jest's existing TypeScript peer dependency. This avoids a second runtime lookup or version-dependent transform path.

This integration should be reevaluated when TypeScript ships a stable programmatic API for the native compiler. Until then, the aliases keep the native compiler and ts-jest's compiler API responsibilities explicit and independently upgradeable.