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 onmicrosoft/TypeScript#54500.

Deprecate --moduleResolution node/node10

welp

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

Deprecate --moduleResolution node/node10

welp

(Sorry if this is offtopic, but is there any way at all for this particular deprecation tonot 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.

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 ourexisting 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 happensentirely 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 isthis particular thing something that's already been decided internally and I should look for more enjoyable uses of my time?

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

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. Oncethat 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 (moduloknown problems). It'll be a bit tricky but we'll get it worked out eventually.

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

???
compiler != application codebase

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

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.

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?

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

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

Yes.#458 (comment)

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