Skip to content

Enhancement: Use TypeScript's Go port (tsgo / typescript-go) for type information #10940

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
4 tasks done
JoshuaKGoldberg opened this issue Mar 11, 2025 · 9 comments
Open
4 tasks done
Labels
blocked by external API Blocked by a tool we depend on exposing an API, such as TypeScript's Type Relationship API enhancement New feature or request

Comments

@JoshuaKGoldberg
Copy link
Member

JoshuaKGoldberg commented Mar 11, 2025

Before You File a Proposal Please Confirm You Have Done The Following...

Relevant Package

typescript-estree

My proposal is suitable for this project

  • I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Description

TypeScript is getting ported to Go! It's going to be 10x faster! Blazing fast! Speed! 🔥 ⚡

https://devblogs.microsoft.com/typescript/typescript-native-port/

If we could use this to power typed linting, that'd be great for users. Type checking performance is the bottleneck for the vast majority of correctly configured lint rules that use typescript-eslint.

We believe there are currently at least three major difficulties with typescript-eslint using tsgo in 2025:

  1. ESLint does not yet support asynchronous parsers: Change Request: allow asynchronous parser eslint/eslint#15475
  2. tsgo is not stable and is many months away from being stable. It won't likely be the primary stable version of TypeScript within the next ~1-2 major versions of typescript-eslint.
  3. ESLint rules in and out of typescript-eslint still rely on the JS-land AST, so even if we had a stable async parser, there's design work to be done communicating AST nodes and type information back from Go/WASM land to JS-land

So, although we'd very much like to be 10x faster (!!), it will take a lot of design exploration and work.

If you'd like to work on this, please go ahead. Seeing your experimentation will help inform how typescript-eslint can adopt faster typed linting in the future. 🚀

Additional Info

If you're coming here because your typed linting is slow, please go through our typed linting performance troubleshooting guide: https://typescript-eslint.io/troubleshooting/typed-linting/performance. Properly configured linting should not be significantly slower than type checking.

💖

@JoshuaKGoldberg JoshuaKGoldberg added blocked by external API Blocked by a tool we depend on exposing an API, such as TypeScript's Type Relationship API enhancement New feature or request labels Mar 11, 2025
@jakebailey
Copy link
Collaborator

  • It's very likely that tsgo will be consumed via native binding APIs (WASM), and so willalmost certainly be asynchronous

FWIW we are working on a number of prototypes which still allow a synchronous API (and hopefully in the browser too).

@nicolo-ribaudo
Copy link

It's very likely that tsgo will be consumed via native binding APIs (WASM), and so willalmost certainly be asynchronous

Note that WASM loading in Node.js will soon not need to be async anymore. You'll be able to just import source wasmModule from "./file.wasm".

@NanderTGA
Copy link
Contributor

typescript-eslint could in theory use something like synckit but that presents data serialization difficulties

If you're looking for a hacky fix, deasync might be the way to go. It uses some C++ code to run asynchronous code synchronously in node. It has some builds for up to node 22, although you should probably look at a few PRs for dealing with promises, the project is pretty dead after all.

@controversial
Copy link
Contributor

Some updates/details on how the API for interacting with tsgo will work, in microsoft/typescript-go#711

@7rulnik
Copy link

7rulnik commented May 28, 2025

@nicolo-ribaudo is there an open issue? If so could you link it please?

@nicolo-ribaudo
Copy link

nicolo-ribaudo commented May 28, 2025

nodejs/node#56919, I think released in 24.0.0.

@controversial
Copy link
Contributor

controversial commented May 28, 2025

The tsgo JavaScript API will be synchronous, and will not use WebAssembly:

typescript-go announcement summary of API progress

There’s a @typescript/api package and a @typescript/ast package, although these don’t seem to be published on npm as part of the first preview release. Example usage looks like:

   test("getTypeOfSymbol", () => {
        const api = spawnAPI();
        const project = api.loadProject("/tsconfig.json");
        const symbol = project.getSymbolAtPosition("/src/index.ts", 9);
        assert.ok(symbol);
        const type = project.getTypeOfSymbol(symbol);
        assert.ok(type);
        assert.ok(type.flags & TypeFlags.NumberLiteral);
    });

Copy link

Uh oh! @controversial, at least one image you shared is missing helpful alt text. Check #10940 (comment) to fix the following violations:

  • Images should have alternate text (alt text) at line 3

Alt text is an invisible description that helps screen readers describe images to blind or low-vision users. If you are using markdown to display images, add your alt text inside the brackets of the markdown image.

Learn more about alt text at Basic writing and formatting syntax: images on GitHub Docs.

🤖 Beep boop! This comment was added automatically by github/accessibility-alt-text-bot.

@mrazauskas
Copy link
Contributor

mrazauskas commented May 28, 2025

Uh oh! controversial, at least one image you shared is missing helpful alt text.

But.. That was actually controversial! The bot should allow certain usernames to have more liberties, or? (Sorry about off-topic.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked by external API Blocked by a tool we depend on exposing an API, such as TypeScript's Type Relationship API enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

7 participants