TypeScript 7 and Beyond: The Go-Based Compiler and the New Defaults

Version note: The code in this post targets TypeScript 7.0 and Node 26.

Predict First

Here's the tsconfig of a project set up a few years ago. It compiled without trouble on TypeScript 5, and before the upgrade someone added the last line to "silence the warnings":

{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "moduleResolution": "node",
    "baseUrl": "./src",
    "outFile": "dist/app.js",
    "strict": false,
    "ignoreDeprecations": "6.0"
  },
  "include": ["src"]
}

What happens when you move to TypeScript 7 with npm i -D typescript and run npx tsc? Does the project compile, or if it errors, for how many settings? Does the ignoreDeprecations line help? We'll answer while talking about what was removed in 7.0.

Project Corsa: The Compiler Moved to Go

We mentioned it in a single sentence in the first post of the series: TypeScript 7.0 came out on 8 July 2026, and its compiler was rewritten from scratch in Go. Internally, the project ran under the name "Project Corsa". For more than a decade, TypeScript's compiler was written in TypeScript and ran on JavaScript; now npm i -D typescript installs a native tsc compiled from Go. According to the TypeScript team's announcement post, full builds are 8 to 12 times faster and use less memory. In a large project, that's the difference between waiting and not waiting.

During the transition this compiler shipped as a preview package, @typescript/native-preview, with the tsgo command. With the 7.0 RC the command became tsc again, and nightly builds moved to typescript@next. The microsoft/typescript-go repository, where the Go port was developed, says the port is complete and is being archived; work has moved back to microsoft/TypeScript.

The most important point is this: 7.0 brought no new language features. Everything in this series, from generics to conditional types, works the same way. What changed is the compiler's speed, the defaults and a few small behaviours. For example, template literal inference now preserves Unicode code points, and JSDoc checking was reworked; we saw the latter in the previous post.

The Defaults That Came with 6.0

TypeScript 6.0, released on 23 March 2026, is the last JavaScript-based compiler. Its job was to be a bridge to 7, and it did that by changing the defaults. 7.0 ships with the same defaults. Every example in this series was written against them:

strict is now true; in a new project you don't have to write anything to get strict mode. module is esnext; target is es2025 in 6.0, and in 7.0 it's the ES version just before esnext. noUncheckedSideEffectImports is on, so for side-effect imports like import "./polyfill.ts" you get an error if the file can't be found. libReplacement is off. rootDir is now the folder that contains the tsconfig.

The change that surprises people most is types: its default is now []. Previously every package under node_modules/@types was included in the project automatically; now none are. In a project that runs on Node you need to write "types": ["node"]. If you want the old behaviour, you can write ["*"]. Alongside these, 6.0 also brought the es2025 lib (RegExp.escape, Iterator and Set methods) and Temporal types under esnext; the dom lib now includes dom.iterable too. 7.0 adds one more thing: stableTypeOrdering, a setting in 6.0, is always on in 7.0.

What Was Removed in 7.0

6.0 declared a set of settings deprecated and let you silence those warnings temporarily with "ignoreDeprecations": "6.0". In 7.0, all of those deprecations are hard errors. Here's the output we got when compiling the opening tsconfig with TypeScript 7.0.2:

tsconfig.json(3,15): error TS5108: Option 'target=ES5' has been removed. Please remove it from your configuration.
tsconfig.json(5,25): error TS5108: Option 'moduleResolution=node10' has been removed. Please remove it from your configuration.
tsconfig.json(6,5): error TS5102: Option 'baseUrl' has been removed. Please remove it from your configuration.
  Use '"paths": {"*": ["./src/*"]}' instead.
tsconfig.json(7,5): error TS5011: The common source directory of 'tsconfig.json' is './src'. The 'rootDir' setting must be explicitly set to this or another path to adjust your output's file layout.
  Visit https://aka.ms/ts6 for migration information.
tsconfig.json(7,5): error TS5102: Option 'outFile' has been removed. Please remove it from your configuration.

That's the answer: the project doesn't compile, and ignoreDeprecations changes nothing; we got the same five errors with and without that line. The value "6.0" means what it says: it only applies to 6.0. Notice that the value "node" shows up as node10 in the message; they're the same old resolution strategy. The rootDir error is also a consequence of the new default: tsc no longer guesses the layout of the output folder, it wants you to state it explicitly.

The rest of the removed list is worth knowing too: --downlevelIteration; classic for moduleResolution; amd, umd, systemjs and none for module; setting esModuleInterop or allowSyntheticDefaultImports to false; alwaysStrict: false; writing module Foo {} instead of namespace; and asserts instead of with on imports. We also saw in the beginner series that passing files on the command line while a tsconfig is present gives TS5112 and needs --ignoreConfig. Here's the same project's config, compiling cleanly with TypeScript 7:

{
  "compilerOptions": {
    "target": "es2025",
    "module": "nodenext",
    "rootDir": "./src",
    "outDir": "./dist",
    "paths": { "*": ["./src/*"] }
  },
  "include": ["src"]
}

We also deleted the strict: false line; the default is now on, and in an old project that's a job in itself. The gradual strict path from the previous post is there for exactly that.

What 7.0 Can't Do Yet

7.0 is a stable release, not a preview. But it has two gaps. First, there's no programmatic API: tools that call the compiler as a library from a Node script don't work with 7.0; that API arrives with 7.1. Second, there are no language-service plugins: editor plugins that check the inside of templates in other file types don't work in 7.0. If you need them, you either stay on 6.0 or install the compatibility package @typescript/typescript6 and use its tsc6 command. On the editor side, there's a TypeScript 7 extension for VS Code, and built-in support in VS Code has been announced.

Then there's the Playground. The TypeScript Playground still runs the JavaScript-based compiler; its version list ends at 6.0.3. The default settings are the same on both sides, but in some edge cases the results can differ. We tried this ourselves:

type FirstChar<S extends string> = S extends `${infer C}${string}` ? C : never;

type Rocket = FirstChar<"🚀 launch">;
const ok: Rocket = "🚀";

In TypeScript 7.0.2, Rocket is "🚀" and the code compiles. When we checked the same file with TypeScript 6.0.3, Rocket held only the first half of the emoji, a meaningless lone UTF-16 fragment, and the ok line gave TS2322. That's exactly what "template literal inference preserves Unicode code points" means. The wording of isolatedDeclarations errors also came out differently in the two compilers. If what you see in the Playground differs from your local tsc, check the version first.

isolatedDeclarations: Let Each File Produce Its Own .d.ts

Speed doesn't only come from the compiler; it also comes from tools not waiting on each other. isolatedDeclarations, which came with TS 5.5, is a product of that idea. Normally, producing a file's .d.ts requires the type checker; the return type of an exported function may depend on types in other files. With this setting on, TypeScript flags every place whose exported type can't be read without the type checker:

export function add(a: number, b: number) {
  return a + b;
}

export const defaultTimeout = 5000;

export const config = {
  retries: add(1, 2),
};

function internalHelper(value: string) {
  return value.trim();
}

When we check this with --isolatedDeclarations --declaration, two errors appear, both TS9013, "Expression type can't be inferred with --isolatedDeclarations.": one on add's return expression and one on retries. defaultTimeout is fine, because a literal's type can be read on its own. The non-exported internalHelper is fine too, because it isn't part of the public API. Once you add a : number return type to add and an annotation to config, the file compiles cleanly. The setting can't be used on its own; without declaration or composite you get TS5069.

What do you gain in return? Bundlers and other tools can produce each file's .d.ts independently and in parallel; in a monorepo, a package can start its work before the package it depends on has finished checking. The cost is clear too: you write more annotations on exports. That's why the TypeScript team recommends turning this setting on in projects that need it, not in every project.

The Type Annotations Proposal: Are Types Coming to the Browser?

At the start of the series we said browsers don't run TypeScript. There's a TC39 proposal that aims to change that: Type Annotations. The idea is for JavaScript engines to treat type annotations like comments and skip them; types wouldn't be checked, they just wouldn't stop the code from running. The proposal is still at Stage 1, and the README in its repository says plainly that it "has not been updated regularly". Don't expect to see it in browsers any time soon.

We already use a practical version of this idea: Node's type stripping. Node 26 strips the types and runs the code; it doesn't type check. That's why we wrote this series' examples as erasable and kept decorators and enums separate. If Type Annotations moves forward one day, the same boundary will most likely apply: types must be erasable.

7.1 Beta and Beyond

The TypeScript 7.1 beta came out on 20 October 2026; the RC is expected about a month after the beta. To try it, npm i -D typescript@beta is all you need; on npm, the latest tag points to 7.0.2, the beta tag to 7.1.0-beta, and next to the nightly builds. You can always check the installed version like this:

npx tsc -v

In our environment this command prints Version 7.0.2. Among the things 7.1 brings: import attributes in ambient modules (with { type: "css" }, plus "text" and "bytes"), source phase imports with import source, the es2026 target and lib (Math.sumPrecise, Array.fromAsync), a new compiler API under typescript/sync, /fs and /ast, content mappers that introduce other file types to TypeScript, and stricter rules for distributive conditional types. The last one directly concerns the distributive behaviour we saw in the conditional types post; it's worth a separate look once 7.1 ships as a stable release.

Common Pitfalls

The first is relying on ignoreDeprecations. That escape hatch worked in 6.0 but doesn't exist in 7.0; you have to actually clean up the deprecated settings.

The second is forgetting the types: [] default. If process or Buffer suddenly can't be found in a Node project, most likely @types/node is installed but the tsconfig doesn't have "types": ["node"].

The third is assuming the Playground and your local tsc always give the same result. One is 6.0.3, the other 7.0; they differ in edge cases.

The fourth is blindly moving a toolchain that depends on compiler plugins or the programmatic API to 7.0. First make sure your tools support 7.0; if they don't, use two compilers side by side for a while with tsc6.

A Small Experiment

★☆☆ Predict whether it compiles: in a new folder, install npm i -D typescript and set target to "es5" in the tsconfig generated by npx tsc --init. What does tsc say, and which error code does it give?

★★☆ Compile the tsconfig of one of your own projects with TypeScript 7.0. For each TS5102 and TS5108 error, find its counterpart in this post's list and turn the setting into its modern form.

★★★ Check the isolatedDeclarations example with --isolatedDeclarations --declaration and fix the errors by adding annotations. Then drop --noEmit, compile with --outDir dist, and compare the generated .d.ts file with the annotations you wrote.

The TypeScript beginner, intermediate and advanced series come together here, but TypeScript doesn't stop. As 7.1 ships as a stable release, and then 7.2 and beyond arrive, we'll add the new features post by post in the same way: predict first, then the code, then what the compiler says. The series will keep growing with new TypeScript versions.