TypeScript 7 Migration: Native Compiler, New Defaults, and Missing API

TypeScript 7.0 is the production release of the compiler and language service ported to Go. For normal command-line use, install the standard typescript package and continue running tsc. The difficult part of migration is not the executable name: 7.0 enforces the defaults and removals introduced through TypeScript 6.0, and 7.0 does not expose the old JavaScript compiler API.

As of August 23, 2026, the stable release is TypeScript 7.0.2. TypeScript 7.1 is expected to introduce a new, different API, so tools that import typescript programmatically may still need TypeScript 6.0 side by side.

Install the native compiler through the usual package

For an application that only invokes tsc, upgrade normally:

npm install -D typescript@^7.0.2
npx tsc --version
npx tsc --noEmit

The old preview package and tsgo command are no longer the production path. The TypeScript 7.0 announcement states that the standard package now supplies the native tsc executable.

Do not carry preview-specific command names into build scripts. Pin an exact version in CI when reproducibility matters, then let the lockfile record the platform-specific packages selected by npm.

The port aims for TypeScript 6.0 type-checking and command-line compatibility. That does not mean every TypeScript 5.x project can skip directly to 7.0: options deprecated in 6.0 become hard errors or have no effect in 7.0.

Use TypeScript 6.0 as the migration bridge

Upgrade to the latest TypeScript 6.0 patch first and remove every 6.0 deprecation instead of hiding it with ignoreDeprecations. The TypeScript 6.0 release guidance describes 6.0 as the transition release and lists the settings that 7.0 removes.

Common changes include:

• Replace moduleResolution: "node" or "node10" with "nodenext" for Node.js or "bundler" for bundler-managed applications.
• Remove baseUrl and make each paths target relative to the project root.
• Replace AMD, UMD, SystemJS, or module: "none" output with a current module target or an external transform.
• Raise target: "es5" to at least ES2015 and remove downlevelIteration.
• Replace import assertions using assert with import attributes using with.

If the deployed runtime still needs ES5 or a removed module format, TypeScript 7 cannot produce that artifact by itself. Keep a compatible compiler or add a documented downstream transform rather than pretending the target is unchanged.

Make new defaults explicit during review

TypeScript 7 adopts the TypeScript 6 defaults, including strict: true, module: "esnext", noUncheckedSideEffectImports: true, libReplacement: false, and a moving modern target. rootDir defaults to the directory containing tsconfig.json, and types defaults to an empty list.

A project should state the intended environment instead of inheriting those defaults accidentally:

{
  "compilerOptions": {
    "strict": true,
    "target": "es2024",
    "module": "nodenext",
    "rootDir": "./src",
    "types": ["node"],
    "noUncheckedSideEffectImports": true
  },
  "include": ["src/**/*.ts"]
}

Choose the target from runtime support, not from the example. Browser applications using a bundler may need module: "esnext" with moduleResolution: "bundler" instead.

The empty types default affects global declarations, not ordinary imported package types. Missing process, test-runner globals, or ambient runtime names usually means the project must install and list the relevant @types package. The new rootDir default can change output paths, so inspect a real emit rather than checking only whether compilation succeeds.

Keep TypeScript 6 for compiler API consumers

TypeScript 7.0 does not ship a programmatic compiler API. Linters, framework language services, code generators, and custom scripts that call functions such as createProgram cannot simply import the 7.0 package.

Microsoft publishes @typescript/typescript6 for this transition. A project whose tools expect the package name typescript can use an npm alias:

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  },
  "scripts": {
    "typecheck": "tsc --noEmit"
  }
}

The alias named @typescript/native installs TypeScript 7 and contributes its tsc binary. The dependency named typescript exposes the 6.0 API to tools that resolve that package name. The compatibility package’s own executable is tsc6, so it does not collide with tsc. These arrangements are documented in the official side-by-side migration section.

Test the exact package manager and workspace layout used in CI. Binary linking and peer-dependency resolution are package-manager behavior, and a tool may insist on a particular typescript version range.

Check editor and framework integration separately

The native language service uses the Language Server Protocol, but embedded-language workflows still depend on extensibility that 7.0 does not provide. The release notes specifically warn that Vue, MDX, Astro, Svelte, Angular templates, and other tools that embed TypeScript may need 6.0 for editor or framework-specific checking until the new API is available.

That limitation does not prevent every mixed setup. A project can run TypeScript 7 tsc for fast project-wide diagnostics while retaining TypeScript 6 for a framework language service. Verify both paths; a successful CLI build does not prove that template diagnostics, language-service plugins, auto-imports, or editor refactors use the intended version.

Benchmark your workload, then tune parallelism

TypeScript 7 parses, checks, emits, and builds project references with parallel work. It defaults to four checker workers. The experimental --checkers and --builders flags can change concurrency, while --singleThreaded disables it for debugging or constrained environments.

More workers can reduce wall-clock time while increasing memory use. --builders 4 --checkers 4 can permit up to 16 checkers across project-reference builds, so do not copy a workstation setting blindly into a small CI runner. Establish a baseline with the default, record time and peak memory on a representative clean build, and change one control at a time.

A complete migration therefore has three gates: the project compiles under the 7.0 defaults, every API-dependent tool has a deliberate 6.0 or new-API path, and editor/framework behavior is verified separately from CLI tsc. Passing only the first gate leaves the most common integration failures undiscovered.