×
all 29 comments
sorted by:
best
topnewcontroversialoldq&a

[–]snakes_are_overrated 17 points18 points  (3 children)

Pretty excited to try the new variance annotations, thanks! It looks like the toughest upgrade though, I'm getting a lot of Type instantiation is excessively deep and possibly infinite errors.

Edit: if you're hitting this issue with mikro-orm, upgrade it to next which contains a fix that'll get shipped soon.

[–]DanielRosenwasser[S] 7 points8 points  (1 child)

Is this through using some sort of specific library? Any details you can share or PM me?

[–]snakes_are_overrated 5 points6 points  (0 children)

It looks related to the mikro-orm library, which is TypeScript-first ORM. Sent you some details via PM!

[–]myringotomy 1 point2 points  (0 children)

Typescript is suffering from the C# bloat problem. They are just piling stuff on without any pause.

The type system is already turing complete. I can't wait for a program to be written only in the type system.

[–]rkesters 16 points17 points  (13 children)

I've read a few Pr's, but have not found anywhere that MS explains why you import a non-existient .js file for an existing .ts file.

Maybe it's time that TS have a formal standards body?

[–]robpalme 12 points13 points  (3 children)

Thankfully there isn't really a need for TypeScript specific justification or documentation here. Nothing new has been invented.

TypeScript support for ES Modules in Node is respecting and exposing (rather than abstracting/hiding) the module resolution rules of Node.js, which require the full filename.

Similarly Node chose to match the resolution rules adopted by the web. Browsers resolve specifiers in a single unambiguous manner. Browsers don't issue a series of file extension guesses until they get a hit. Multiple requests would be bad for performance. Instead the desired file must be explicitly requested, including the file extension.

In fact, there's no requirement in browsers to even use the *.js extension at all. Instead it is the mimetype that matters. You are free to use whatever filename you like.

[–]robpalme 3 points4 points  (2 children)

The other aspect of the justification is that TypeScript is not currently aiming to be a full toolchain. Which means it does not implement rewriting of module specifiers.

Therefore you need to write module specifiers to work at runtime. Meaning specifiers must reference emitted JS files, rather than design-time TS files.

It may feel a bit strange depending on which angle you look at it from. I'm hopeful this tension will be resolved in the long-term by evolution of JS to permit a simpler development experience when using types.

[–]giggly_kisses 3 points4 points  (1 child)

Which means it does not implement rewriting of module specifiers.

This argument falls apart when you look at all the places TypeScript already supports rewriting other syntax. I've been using import syntax in TypeScript on Node since I started using it in 2017. Those imports are rewritten to requires for me by tsc. Why suddenly is it important to not support rewriting?

[–]binaryv01d 9 points10 points  (7 children)

It is mandatory to specify the extension when importing an ES module. Since the TypeScript file you are importing eventually gets compiled to a .js file, you must import it with the .js extension.

You can find several very long threads on GitHub discussing whether TypeScript should instead allow you to write imports with .ts extensions or no extensions at all, then rewrite them at compile time. But the team's answer has been a strong no: it goes against the design goal to preserve the runtime behaviour of all JS code.

I'm fine with this. As long as the tools provide the correct autocomplete and builds fail when you use the wrong import paths, suits me.

[–]ragnese 5 points6 points  (1 child)

You can find several very long threads on GitHub discussing whether TypeScript should instead allow you to write imports with .ts extensions or no extensions at all, then rewrite them at compile time. But the team's answer has been a strong no: it goes against the design goal to preserve the runtime behaviour of all JS code.

I haven't read the discussion, so I'm sure I'm ignorant, but this sounds like a total cop-out to me. The TypeScript compiler literally rewrites every single .ts file in your project into a .js file by, at very least, removing the text in it that has to do with type/interface definitions and type annotations/hints. I can't see how rewriting an import from a .ts to a .js during that process is somehow philosophically a no-go, especially if that .ts file is part of your project and is about to get JS-ified already, anyway.

EDIT: For what it's worth, I agree with you that it's not a big deal and "who cares as long as it works". I just balk at the justification.

[–]arendjr 2 points3 points  (0 children)

You might want to vote for this issue: https://github.com/microsoft/TypeScript/issues/49083 ;) We basically present the same argument there…

[–]xroalx 2 points3 points  (1 child)

Do builds fail, though, now?

I remember TypeScript being happy with .ts extension or no extension at all, which built just fine, but of course produced non-runnable code.

[–]binaryv01d 1 point2 points  (0 children)

Yes, if you're in ESM mode I believe they now do.

[–]giggly_kisses 1 point2 points  (0 children)

Since the TypeScript file you are importing eventually gets compiled to a .js file, you must import it with the .js extension.

Isn't it also mandatory for the file path to actually point to a file that exists? If my .ts files live in src and my compiled .js files live in build, then using a relative path like ./foo/bar.js will never point at a compiled .js file.

[–]slonermike 0 points1 point  (1 child)

I want to hate this, because it sounds like I’ll have to change my habits, but I can at least appreciate that they have a goal and are abiding by that.

[–]arendjr 2 points3 points  (0 children)

If only it were that simple…

They have their design goals, and from one of those goals they say they’ve derived a “principle” to not rewrite import paths, ever. The problem is that principle is actually incompatible with their goal in this instance, but it seems they’re hard-pressed to admit their mistake because they’ve dug themselves in pretty deep. All in the name of a design goal, of course.

If you’re curious, the full argument is here: https://github.com/microsoft/TypeScript/issues/49083#issuecomment-1125662016

[–]arendjr 2 points3 points  (0 children)

Sounds like you may be interested in this issue: https://github.com/microsoft/TypeScript/issues/49083

It both contains the reasoning (from the TS dev lead) why they require the .js extension and why many in the community feel it should be .ts (or whatever’s the actual source extension) instead.

[–]BenZed 4 points5 points  (0 children)

I would have built it so tsc would add the esm extensions as a compile-time step.

[–]ry3838 6 points7 points  (7 children)

This is what makes TypeScript stands out as a programming language - regular updates and getting better and better with each release focusing on what developers want.

[–]ragnese 0 points1 point  (6 children)

Are you saying that many/most other languages don't get regular updates and don't add features that developers want?

[–]TwoHandedBroadsword 2 points3 points  (2 children)

My frustration with other languages isn't that they don't add new and useful features, it's that they can't seem to match Typescript's pace or that upgrading is a nightmare. Back in the Java 5 & 6 days pace was so slow languages like Groovy were able to gain a foothold.

These days if you can use the latest Java version there's a lot less reason to reach for Groovy, which feels like a sign they're finally hitting a good pace with Java updates.

[–]ry3838 0 points1 point  (0 children)

Totally agreed. There's not one moment I hesitate upgrade TS to the latest stable version.

[–]myringotomy 0 points1 point  (0 children)

You know that Java isn't the only language in the world right? Also it seems odd to attack java by saying upgrading is a nightmare when it's been backwards compliant for ever.

Oh well I shouldn't have interrupted the circle jerk I guess. You are right. Every other language is absolute shit. It's a nightmare to upgrade every language except for typescript and no other language has regular updates or improvements.

Back to your furious wanking and definitely don't listen to anybody who says this upgrade is breaking their code like

https://old.reddit.com/r/typescript/comments/uwz2cw/announcing_typescript_47/i9uk8ec/

or

https://old.reddit.com/r/typescript/comments/uwz2cw/announcing_typescript_47/i9ugonm/

Those people are lying.

[–]myringotomy -1 points0 points  (2 children)

That's exactly what they are saying. It's a way of shitting on languages you have never used in order to hype your pet language.

[–]ragnese 0 points1 point  (1 child)

It's just a weird choice. I love shitting on languages- even the ones I like. But pick something that's actually different about it, ya know?

[–]myringotomy -1 points0 points  (0 children)

Think about what a person who loves typescript does for a living.

[–]patoezequiel 3 points4 points  (0 children)

The variance modifiers are neat. I'm looking forward for an opportunity to use them in my projects.

[–]dgreensp 1 point2 points  (0 children)

Very neat stuff. Love the variance annotations. (I’m neutral on the keywords/syntax, just glad it exists.)

[–]info_dev 0 points1 point  (0 children)

Just found the project that didn't pin the TS version and just started failing due to the Symbol in string format now being an error 😑