---
name: typescript-7-tsgo-native
description: "Adopt TypeScript 7's Go-native compiler (tsgo): install the RC, run compat checks, wire up the LSP, benchmark ~10x type-check speedups. Migrate to TypeScript 7's Go-native compiler (Project Corsa): install @typescript/native-preview and run tsgo --build alongside legacy tsc, verify config and tsconfig compatibility (extends, project references, paths, declaration emit), switch VS Code to the native LSP via typescript.experimental.useTsgo, and benchmark cold type-check times against tsc 5.x on a real monorepo. Covers known RC gaps (no API/transformer plugin parity yet, partial build-mode coverage) and a safe dual-runner CI rollout."
license: MIT
---

# TypeScript 7 Native

TypeScript 7 reimplements the compiler in Go (the effort Microsoft calls Project Corsa), shipping it as the `tsgo` binary for roughly 10x faster type-checking and project loads. This skill walks you through adopting it incrementally: installing the preview, running `tsgo` next to your existing `tsc` to confirm identical diagnostics, switching VS Code to the native language server, and measuring the speedup on your own repo. It's for teams with large codebases or slow editor responsiveness who want to trial the native port before it becomes the default in the TypeScript 7.0 release.

## When to use it

- Your monorepo's `tsc --build` or editor "loading…" times have become painful and you want to benchmark the native compiler against them.
- You're evaluating whether your `tsconfig.json` setup (project references, `extends` chains, `paths`, declaration emit) is compatible with `tsgo` today.
- You want CI to run `tsgo` for fast feedback while keeping `tsc` as the source of truth during the transition.
- You're setting up the experimental native LSP in VS Code and need the right settings flag.

## How it works

The skill installs `@typescript/native-preview`, which vendors the `tsgo` executable. It runs `tsgo --build` (and plain `tsgo -p tsconfig.json`) over your project and diffs the emitted diagnostics and `.d.ts` output against legacy `tsc` so you can spot any divergence. It checks for current preview gaps — some compiler APIs and config edge cases aren't ported yet — and reports what's safe to switch. For the editor, it enables the Go-based language service in VS Code via the `typescript.experimental.useTsgo` setting (from the TypeScript Native Preview extension), which replaces the JS-based tsserver.

## Usage

```bash
curl -fsSL --create-dirs -o ~/.claude/skills/typescript-7-tsgo-native/SKILL.md https://claudeskil.com/skills/typescript-7-tsgo-native/SKILL.md

# install the preview compiler
npm i -D @typescript/native-preview

# type-check with the native compiler
npx tsgo --build tsconfig.json

# benchmark against legacy tsc
time npx tsc --build --force
time npx tsgo --build --force
```

VS Code settings to try the native LSP:

```jsonc
{ "typescript.experimental.useTsgo": true }
```

## Tips & gotchas

- `tsgo` is a type-checker and emitter, not a full programmatic replacement yet — third-party tools that import the `typescript` package API (ts-loader, custom transformers, ESLint's type-aware rules) still run on the JS compiler.
- Pin the preview version; nightly builds of `@typescript/native-preview` change behavior frequently.
- Keep `tsc` as your CI gate of record until diagnostics match exactly on your codebase. Treat `tsgo` as the fast pre-check, not the authority.
- The native LSP and the classic tsserver shouldn't both own type info — disable one per workspace to avoid duplicate diagnostics.

## FAQ

**Does this change my `tsconfig.json`?** No. `tsgo` reads the same config format, including `extends`, references, and `paths`. The skill only verifies compatibility.

**Is the ~10x number real?** It's checking speed; gains vary by codebase. The skill benchmarks your repo so you get a real figure rather than the headline.

**Can I ship to production with it?** Treat it as preview. Validate emit output before relying on `tsgo` for builds.