This proposal regarding TypeScript version

[hydroper]

I've just now tried TypeScript to startup the following technology combination:

• Node.js + Prisma ORM + ExpressJS

Surprise? I've tried to integrate the cors NPM package and got a TypeScript version conflict as the cors package was requiring a specific TypeScript version range (an old version: 3.x to 4.0). I gave up on TypeScript and ended up with JSDoc.

I think this proposal would be very useful!

(Or I'm not sure... Maybe I used a problematic TypeScript template that contained a problematic dependency.)

[oelmekki]

I support this proposal for a similar reason: I'm tired of wasting my life managing dependencies (upgrading them on all my projects, refactoring for breaking changes, dealing with things going unmaintained, etc), so I go all-in vanilla-js, nowadays. Having types backed in ecmascript would be a game changer, for me. I'm using JSDoc, right now, but it still forces me to use Typescript to perform static analysis (at least, I don't depend on it, as my code runs unmodified in the browser).

So yeah, thank you for the proposal, maintainers. :)

[lillallol]

If JSDoc (coupled with TS) works, then why do we need the context proposal (given also the drawbacks that it brings)?

[oelmekki]

@lillallol Please read my comment, your answer is in it.

[lillallol]

This proposal is about reserving syntax space in EcmaScript in which any kind of type system that conforms to that syntax can exist. You will not get TypeScript into that syntax space. You have to introduce breaking changes into TypeScript for it to live into that syntax space. Static analysis will not be performed by EcmaScript or browsers. You will still need third parties for that. This proposal is about future proofing the TypeScript syntax by just breaking in it one last time, i.e. making sure that future EcmaScript proposal will not introduce breaking changes into TypeScript.

As you people already said .js + JSDoc + TS works. Projects like Deno, Svelte, Preact, Webpack, remark, eslint, etc, work like that. There is no need to reserve syntax for something that already works.

[oelmekki]

Give it a few more years and you'll understand why this way of thinking is bogus - when you'll see all your tools "software rot" to death, or become impossibly bloated before everybody give up on them. There's a reason we have standards, you'll understand them after a decade or two of programming. And this is what this proposal is about. If you don't like nor understand standards, maybe your input on a discussion about standards is not as useful as you think.

And by the way, yes, you can very much expect that browsers' devtools will implement static analysis when they will start supporting this. They already do it in many ways, they even implement full blown debuggers, this is exactly their turf.

[lillallol]

when you'll see all your tools "software rot" to death or become impossibly bloated before everybody give up on them

These are all my tools:

• VSCode
• tsc --noEmit

How are these going to "software rot" to death or become impossibly bloated before everybody give up on them?

nor understand standards

Have you actually taken a look at the tc39 meeting notes for the context proposal?

And by the way, yes, you can very much expect that browsers' devtools will implement static analysis when they will start supporting this. They already do it in many ways, they even implement full blown debuggers, this is exactly their turf.

Why do we need to reserve extra syntax space for that when it can already happen without reserving the extra space?

Oh and by the way I forgot to mention that a working syntax has not yet been proposed, and that the JS parser will become slower.

[azder]

Having types backed in ecmascript would be a game changer

They already are, just not the way you like it, so you dismiss them? There are no types in JS because they aren't up to the "let's write code for the static compiler and type checker" crowd standard?

You can have simpler compilers to build and maintain if you have languages that require you specify types ahead of time, sure. But then we end up writing code for the compilers, not the people.

The other solution is to just write code that is easy for people to read and write. Compilers can get more sophisticated with time. AI can become better with time and it will be faster at generating loads of static or dynamic code more than us in any way.

So, just adding syntax into ES that is already supported in languages that transpile to ES... I can see some short term benefit, maybe more emotional than practical for everyone raised to see and express the world through static typing, but long term just syntax bloat that once introduced into ES can't be taken out.

Unlike other languages ES can't quite support adding stuff now just to see if it will work out and maybe releasing a breaking change later that removes it.

[hydroper]

The case is lost then. The web standards for existing JavaScript have gone through an entirely different path from ECMAScript 4; otherwise explicit typing in the form of runtime types would be ideal for ECMAScript.

TypeScript versus ECMAScript 4:

• Full type inference
• Version conflicts may happen
• Type erasure

Either way, build steps are almost always needed due to XML user interface frameworks. For example, the Flex compiler for ActionScript 3 processed special files called MXML files, similiar to .NET Razor.

[hydroper]

You may also check my prespecification of a language called Jet that is based on ECMAScript 4: https://hydroper-jet.github.io/lang/spec/1.0/live/

No, I'm not planning to work on it definitely anymore, but it points to an ideal type system; read the Language Overview section.

[markcellus]

Hmm I'm not entirely sure what the issue is here. Is there any question or something we can help understand? FWIW, there are a ton of other issues open that discuss the pros and cons of this proposal. Based on the OP, it sounds like you're having compatibility issues with TS versions, which I don't think this proposal is focused on.

[hydroper]

@markcellus Surely, the TypeScript varying version behavior might not be of interest when it comes within the IDE.

This proposal will, still with type erasure, be useful to avoid setting up TypeScript projects 👍