What will happen to the existing TypeScript/JavaScript codebase?

[DanielRosenwasser]

Will everyone have to upgrade to the native version of the compiler and language service? What if there's a huge problem with the new codebase, or tools and projects need to continue using the JavaScript-based codebase?

---

We expect that many users will need to continue using the existing stable TypeScript codebase (versions 5.x and 6.x, a.k.a. Strada) for pragmatic reasons, even as adoption of the new native codebase (eventually version 7.x, a.k.a. Corsa) picks up. There are a few reasons for this.

First, the new codebase is not yet at complete parity, and there may be cases where developer feedback tells us about some gap between the two implementations. Some of these omissions may be intentional, and others may not, and we will be listening to feedback to understand what gaps are blocking adoption of Corsa. Beyond that, many programs depend on TypeScript's APIs (e.g. the compiler and language service APIs, the TSServer protocol, or language service plugins). Even if there was perfect compatibility in the parser, checker, CLI, etc., any missing integration might pose challenges for existing TypeScript users to upgrade.

For these reasons, we expect to maintain the existing TypeScript codebase for the foreseeable future. We will continue to release new versions of TypeScript 5.x and 6.x, and we will continue to support the existing APIs in the Strada codebase (though note that we will not port all APIs to Corsa as we are rethinking API compatibility). We will also continue to accept pull requests and issues against the Strada codebase, and we will strive to keep the two codebases in sync and compatible in type-checking and other behaviors. Eventually, the intent is to develop only the Corsa codebase, but this will be decided based on adoption and the state of the community.

[LeviticusMB]

Will you be porting over legacy and lesser used (I would assume) features of current tsc too? Thinking of the ability to output ES5+downlevelIteration+AMD, for instance.

[DanielRosenwasser]

We are trying to find ways to make existing JS/JSDoc support simpler, so there may be a few divergences there, but we are specifically looking for feedback.

For other stuff, you can keep track of relevant deprecations on microsoft/TypeScript#54500.

[egasimus]

Deprecate --moduleResolution node/node10

welp

(Sorry if this is offtopic, but is there any way at all for this particular deprecation to not happen?)

[PaluMacil]

Deprecate --moduleResolution node/node10

welp

(Sorry if this is offtopic, but is there any way at all for this particular deprecation to not happen?)

@egasimus It's been a long time since I dealt with commonJS imports, but thinking about the change, I wonder if it might not be bad to migrate even a very large project since the compiler will tell you if you missed anything. While there might be a lot of changes, some might be scriptable and other changes fairly brainless. I know it's a pain, but I've done some pretty massive refactors without problems when I've been able to lean on knowing the compiler won't let me forget something.

[egasimus]

CommonJS is indeed out of scope for the use case I have in mind, and in general I really wouldn't like to water down these threads with such abstract discussion. Especially considering the subject of my question turned out to be only tangential to the planned Go rewrite.

I'm only soliciting input from TypeScript core team members and only as to whether there exists any way at all to dissuade them from effecting this deprecation, thus permitting our existing post-compilation scripts¹ to continue working into the TypeScript 6.0 era; or should we rather begin preparing to undergo a new round of what @PaluMacil perhaps dismissively, but as it happens entirely aptly described as "pain".

Since the issue linked by @DanielRosenwasser is locked, is the proper course of action to open an issue on the TypeScript repo proper — or is this particular thing something that's already been decided internally and I should look for more enjoyable uses of my time?

Footnotes

1. Which we shouldn't have needed to develop anyway, were it not for TypeScript and Node.js innovating in opposite directions around "moduleResolution": "node16". In the three years since, I've found that Deno does not exhibit most of the problems that result from the official "solution"; we remain, however, significantly locked into the Node.js and TypeScript ecosystems. ↩

[mikegwhit]

As a CommonJS author using lots of JSDoc I'm interested in how I can leverage TypeScript using JSDoc and what is going on here. CC @DanielRosenwasser

[IllusionMH]

Any changes to how external contribution should proceed in the meantime?
Is it possible to submit PR just to typescript (Strada) repo? Would it be stricter consideration of what is marked as help wanted or there would be new expectation that it should be done to both repos?

[RyanCavanaugh]

No changes in guidance in external contributions yet (other than "please have patience as we're quite busy" 😅). Our general plan is to have us port the PRs that have gone in since we forked, then figure out how to get this repo merged back into the primary repo. Once that happens then we'll have some strategy around testing to make it ergonomic to make the same change to both codebases and validate that the "same" diff occurs (modulo known problems). It'll be a bit tricky but we'll get it worked out eventually.

[ndiuky]

What will happen to TypeScript applications that were transpiled to JavaScript and ran in the browser, and will older browsers support all of this?

[RyanCavanaugh]

Nothing; this affects the implementation of TypeScript itself, not applications written in TS

[0xF6]

???
compiler != application codebase

[mikegwhit]

Glad to see this @RyanCavanaugh I think I posted a question relating to this here #503 and I think you helped clarify thanks.

[dlokman]

[jakebailey]

TypeScript the language is not changing; the compiler that checks your code and provides editor features is. You will not need to learn Go unless you want to contribute to the project.

[jschuttler]

TypeScript the language is not changing; the compiler that checks your code and provides editor features is. You will not need to learn Go unless you want to contribute to the project.

Sorry if this was made clear - while I understand that the language itself is not changing, how will it evolve? Will syntax become less coupled with Javacsript or continue to maintain relative parity?

[lofcz]

What will happen to Monaco Editor with TypeScript 7? In terms of TypeScript Intellisense.

[jakebailey]

Monaco can support LSP based languages, so we should be covered there.

[troy351]

Maybe there will be WASM version of TypeScript running in the browser?

[jakebailey]

Yes. #458 (comment)

[magic-akari]

I understand that Strada (5.x, 6.x) will reach end-of-life when Corsa (7.0) is fully adopted.

Given that TypeScript has been reimplemented in Go, would the team consider supporting JavaScript environments through Go-to-JavaScript compilation tools like GopherJS?
This could provide continued compatibility for projects requiring JavaScript API( and wasm is not available) while leveraging the new Go-based implementation.

[jakebailey]

Possibly, though GopherJS is unfortunately very behind in supporting newer versions of Go.