Repository navigation
Feature Suggestion: Static Indexing Format for Compiler #63770
Description
Hi TypeScript team! Congratulations for the new TypeScript-Go release!
I understand that the new Compiler API is currently under design and development. However, I want to discuss the possibility of introducing a static indexing format from the TypeScript compiler that creates a snapshot of the codebase for external tools to consume.
Intriguing Example
We already have fast TypeScript linters in Rust, but they cannot handle type-aware linting. Even if TypeScript-Go is fast and provides Go API, the community needs to repay the effort to rewrite a new linter in Go. Or JS-based tools need to talk to Go using FFI.
Alternatively, a language agnostic language server indexing can help external tools utilize type information.
Design Consideration
This is not a new idea. LSIF from Microsoft and SCIP from Sourcegraph are two prominent examples for type indexing.
While it is less flexible than the Compiler API, it opens up new opportunities for various use cases. LSP/copmiler API are dynamic and interactive. APIs can even read/write/transform code on the fly (e.g. like Vue/Svelte/Angular language tools).
In contrast language indexing provides an offline and static alternative for code analysis and manipulation.
Of course, if TS-go can provide a compiler API in JS/Go, implementing indexing can be done in userland. But if it is hard to ship a JS-Go FFI, the indexing format can be a good workaround.
Usage
- Offline code browsing like GitHub/SourceGraph
- Non-JS/non-Go linter integration, e.g. biome, ast-grep
- Code auditing for compliance and quality checks
- Automated code rewriting based on types
Activity
Brooooooklyn commentedon Mar 12, 2025
I'm working on related attempts in this repo https://github.com/Brooooooklyn/typescript-go-napi
0xdevalias commentedon Mar 12, 2025
LongYinan (@Brooooooklyn) At the risk of being slightly off topic.. (issues weren't open there, so couldn't ask on the repo itself) would you see that as (eventually) being able to be compiled to web assembly and consumed within a service worker/similar? (eg. with Monaco). Or would that be outside of the scope of what you're looking into there?
Brooooooklyn commentedon Mar 12, 2025
Glenn 'devalias' Grant (@0xdevalias) Go compilation to WebAssembly has very poor performance: https://x.com/youyuxi/status/1899701468480897443. so compiling to WebAssembly is not the primary goal of ts-go-napi. I will try to port capabilities like transform and typecheck to the JS API, so everyone can easily develop tools like ts-loader.
0xdevalias commentedon Mar 12, 2025
LongYinan (@Brooooooklyn) Ah true, that sucks :(
LongYinan (@Brooooooklyn) Makes sense :)
jakebailey commentedon Mar 12, 2025
#514 is discussing this topic.
I for one don't understand the perf numbers; if you have your testing methodology then that would be best posted there. We did not intend for people to right out the gate try and run this repo in WASM; concurrency is enabled by default when it should not be in WASM.
But I think this is off-topic for this thread.
jakebailey commentedon Mar 12, 2025
Also note that we are also working on support for the API, and that NAPI is off the table for Go because you can't load multiple Go libs into the same process safely. We tested that out a good while ago.
RyanCavanaugh commentedon Aug 20, 2026
We're definitely providing APIs for people to write the offline formats they want.
I don't think it's tractable for us to accurately predict all the kinds of questions that you might want to have answers to -- a common thing is stuff like "is X assignable to Y?" for two arbitrary X and Y types, and it's hard to imagine computing that full matrix into a file, let alone correctly computing the closure of all possible types in a program.