I originally posted this proposal in the GitHub Discussions for Microsoft's TypeScript Native (typescript-go) project. I personally feel it might receive more dicussions on Hacker News, so I've reposted the full text here. Comments and feedback are welcome.
[ORIGINAL]
Title: Proposal: Extract the Parser of TypeScript Native into a standalone Go Module to fill a gap in the Go ecosystem and benefit this project
I suggest extracting the Parser component from typescript-go and publishing it as an independent Go library.
Currently, the Go ecosystem severely lacks a complete, standard-compliant JavaScript/TypeScript/JSX parser. typescript-go actually possesses what is likely the most comprehensive Parser in the current Go ecosystem. If this could be decoupled, it would become a foundational cornerstone for frontend tooling within the Go language.
Rationale:
1. It fills a structural gap in the Go ecosystem.
In the JS ecosystem, TypeScript doesn't need a standalone Parser because tools like Babel are already very mature. However, in the Go ecosystem, there is currently no comparable infrastructure.
As frontend toolchains migrate toward high-performance native languages, Go is highly attractive to the vast community of JS/TS developers due to its ease of learning and concurrency advantages. By filling this void, Microsoft would allow external tools to reuse this core capability without needing to reinvent the wheel.
2. An independent Parser will attract integration from numerous external tools.
This means massive amounts of real-world codebases will be used to test this Parser. Edge cases discovered and fixed by the community can be fed directly back into typescript-go. This is far more efficient than relying solely on internal test cases and will significantly improve the robustness of the Parser.
3. From an engineering perspective, decoupling the Parser helps define project boundaries and improves maintainability.
Implementation-wise, this does not require rewriting core logic; it only involves adjusting the project structure to support Go Module referencing, making the engineering effort manageable.
4. TypeScript has, in a sense, become a de facto standard.
If Microsoft provides an official Go version of the Parser, it ensures that Go-based frontend toolchains maintain high consistency with the native TS compiler in parsing behavior. This prevents the community from creating various incompatible "dialect" parsers due to a lack of standards, thereby avoiding ecosystem fragmentation.
narukeu•22h ago
I originally posted this proposal in the GitHub Discussions for Microsoft's TypeScript Native (typescript-go) project. I personally feel it might receive more dicussions on Hacker News, so I've reposted the full text here. Comments and feedback are welcome.
[ORIGINAL]
Title: Proposal: Extract the Parser of TypeScript Native into a standalone Go Module to fill a gap in the Go ecosystem and benefit this project
I suggest extracting the Parser component from typescript-go and publishing it as an independent Go library.
Currently, the Go ecosystem severely lacks a complete, standard-compliant JavaScript/TypeScript/JSX parser. typescript-go actually possesses what is likely the most comprehensive Parser in the current Go ecosystem. If this could be decoupled, it would become a foundational cornerstone for frontend tooling within the Go language.
Rationale:
1. It fills a structural gap in the Go ecosystem.
In the JS ecosystem, TypeScript doesn't need a standalone Parser because tools like Babel are already very mature. However, in the Go ecosystem, there is currently no comparable infrastructure. As frontend toolchains migrate toward high-performance native languages, Go is highly attractive to the vast community of JS/TS developers due to its ease of learning and concurrency advantages. By filling this void, Microsoft would allow external tools to reuse this core capability without needing to reinvent the wheel.
2. An independent Parser will attract integration from numerous external tools.
This means massive amounts of real-world codebases will be used to test this Parser. Edge cases discovered and fixed by the community can be fed directly back into typescript-go. This is far more efficient than relying solely on internal test cases and will significantly improve the robustness of the Parser.
3. From an engineering perspective, decoupling the Parser helps define project boundaries and improves maintainability. Implementation-wise, this does not require rewriting core logic; it only involves adjusting the project structure to support Go Module referencing, making the engineering effort manageable.
4. TypeScript has, in a sense, become a de facto standard.
If Microsoft provides an official Go version of the Parser, it ensures that Go-based frontend toolchains maintain high consistency with the native TS compiler in parsing behavior. This prevents the community from creating various incompatible "dialect" parsers due to a lack of standards, thereby avoiding ecosystem fragmentation.