It’s great to see ESM support coming along (my word is this stuff confusing, I hope ESM settles it all… eventually)
but man there are a lot of file extensions going around these days!
It makes sense why all these things are needed. I don’t know how many of them a single project would have to deal with (not many if starting with Typescript, I think).
Totally. And then the module formats of .js and .ts files are anybody’s guess without peeking inside.
Wow, lots of features that will really make a difference in day-to-day use. Not having “Go to Source Definition” has been one of the biggest annoyances in TypeScript / VS Code, this will really improve quality of life.
Also quite excited about the “Organize Imports” improvements, we have several files where we need to import in a particular order (mainly polyfills, dotenv, etc.), and the only solution at the moment is to use “Save without formatting” in VS Code.
I’m massively dreading the switch to ESM though, having to import “foo.js” filenames in TypeScript is just such a confusing decision, and the benefits are… what exactly?
Some NPM modules have decided to go “ESM-only” (eg. quick-lru), so I’m hoping that we’ll be out of this weird limbo phase soon.
As far as I can tell the only result of switching to ESM will be competing standards.
Can you clarify what you mean? ESM is already one of the “competing standards.” How does switching to ESM change that?
If anything, I’d think that folks switching to ESM is the only path forward to reducing fragmentation, because unlike the other approaches, ESM is actually the language standard.
CommonJS was a de facto standard before ESM was invented, and the increasing adoption of ESM increases fragmentation of the ecosystem for no reason. If it was desirable to have modules in the language standard, and to keep fragmentation low, making CommonJS the language standard would have made the most sense. Clearly that wasn’t a concern.