How I Made TypeScript Instantly Faster in VSCode Without Touching My Build

Why TypeScript Feels Slow in Big Projects

Large TypeScript projects get slower over time. Even with features like incremental builds, tsc can still lag. This slows down autocomplete, error checks, and general development in VSCode.

I wanted things to feel faster, without breaking production builds.

Then I found tsgo, a TypeScript compiler built in Go. It’s much faster. But it’s not a full replacement for tsc. Some tools expect tsc to behave a certain way, and tsgo doesn’t match that exactly. Use with care.

Easy Way to Make TypeScript Faster

Use tsgo only inside VSCode and not for building your app. This makes type-checking, autocomplete, and errors faster, while keeping tsc for builds and CI. Fast where it matters, safe where it counts.

Steps:

• Install the TypeScript (Native Preview) extension in VSCode

• Install tsgo in your project

• Set VSCode to use tsgo as the TypeScript server

• Don’t remove tsc. Keep it in devDependencies and use it in tsconfig.json, build scripts, and CI jobs.

Deep Dive

Under the Hood: How the tsgo Setup Works

VSCode doesn't run your project's tsc when showing type errors. It uses its own TypeScript server, which interprets your code through a bundled TypeScript SDK. That SDK is swappable.

By pointing the editor to a custom SDK backed by tsgo, you override the default runtime used for language features without touching build tools or scripts. This creates a forked workflow:

• Editor: uses tsgo for rapid feedback

• Build: still uses tsc to ensure correctness and compatibility

This separation isolates the speed boost to development only, avoiding compatibility issues with things like:

• tsc --build mode

• Project references

• Babel transforms that depend on TypeScript emit

You get a lighter TypeScript experience during coding, while builds remain stable.

Code Walkthrough / Demo

Step 1: Install @typescript/native-preview This package contains the patched TypeScript SDK that knows how to invoke tsgo. Install it locally:

npm install --save-dev @typescript/native-preview

This ensures the tooling stays project-scoped and versioned.

Step 2: Install the VSCode Extension Install the TypeScript (Native Preview) extension from the VSCode marketplace. This extension allows VSCode to switch its TypeScript server to the native Go-powered one.

Step 3: Enable tsgo in VSCode Settings Update your project-level .vscode/settings.json:

{
  "typescript.experimental.useTsgo": true
}

This directs the Native Preview extension to use tsgo as its engine for TypeScript diagnostics.

Step 4: Verify Compatibility Before trusting the editor, confirm that tsgo parses your current config correctly:

npx tsgo --project ./tsconfig.json

If this fails, it’s likely due to unsupported options or syntax. Do not proceed until this passes. This step confirms the Go-powered compiler can interpret your setup.

Challenges & Tradeoffs

1. Not a Full Replacement tsgo only supports a subset of tsc functionality. It skips emit logic, type emit transformations, and rarely-used compiler flags. This makes it fast, but incomplete. Using it in build pipelines or scripts will break under non-trivial setups.

2. Misleading Error Surfaces Because tsgo runs in the editor only, its diagnostics may slightly diverge from actual tsc output. It’s rare, but in complex projects with transformers or custom emit targets, you may get false negatives or miss real errors until build time.

3. CI/CD Blind Spot If you mistakenly switch your build scripts to rely on tsgo, you risk subtle breakages in your pipeline. Most tooling expects canonical tsc behavior. Keep tsgo scoped to local development only.

4. IDE Dependency The performance gain only applies within VSCode. External tooling, test runners, and linters still rely on tsc, so global performance won’t change unless you’re running everything in the editor.

5. Extension and SDK Sync The @typescript/native-preview version and the VSCode extension must stay in sync. If the SDK updates but the extension doesn’t, or vice versa, you may see version mismatches or degraded editor support.

6. Fixing Auto-Import Issues If auto-imports stop working after switching to tsgo, install the Auto Import — steoates extension for VSCode. It restores import suggestions using your tsconfig paths and works well with tsgo.

Use tsgo as a scoped optimization, not a build foundation. Treat it as a dev-only patch layer.

Results / Takeaways

After integrating tsgo into my editor workflow, TypeScript feedback became near-instant. Error squiggles, autocomplete, and refactor previews all responded faster, especially in large monorepos or deeply nested modules.

Build times remained untouched. CI pipelines stayed stable. No regressions appeared, since tsc still handled all production and testing tasks.

The separation proved effective:

• Faster iteration during development

• Full correctness during build

• Zero change to deployment logic

The only caveat: treat the setup as non-global. If you work across multiple repos, you’ll need to configure each one independently. This is a one-time cost that pays off with every keystroke.

Further Exploration

Want to try this setup in your project? Start with a side branch. Run npx tsgo --project ./tsconfig.json to confirm compatibility before enabling it in the editor.

If you've used tsserver performance hacks before, compare them directly with tsgo and watch the difference.

Pro Tip: Keep your .vscode/settings.json project-scoped and committed. That way, your entire team benefits from the same dev feedback loop without affecting builds.

Repo: tsgo on GitHub Related: TypeScript (Native Preview) Extension Reading: TypeScript Performance Docs