3 ms·
The whole point of this is that ESM was very poorly handled. It's irrelevant to TypeScript, esbuild, Webpack, etc. That tooling handles the complexity for you a
by dimgl 2y ago
The whole point of this is that ESM was very poorly handled. It's irrelevant to TypeScript, esbuild, Webpack, etc. That tooling handles the complexity for you and sometimes that backfires. I've run into a lot of headaches with the TypeScript compiler.
The fact that you don't know whether your codebase uses TypeScript, esbuild or Webpack is disappointing. It means that those worries have been handled for you and you don't care to learn them, which is never a good stance if you work with this on a daily basis. But I somewhat agree that it should all be vastly simpler.
I also kind of agree with the downvoted/flagged comment re: Golang. The way the JavaScript ecosystem works is highly dependent on the way Node is handled. And Node has, for many years, made ESM needlessly complicated.
- knallfrosch 2y ago> The fact that you don't know whether your codebase uses TypeScript, esbuild or Webpack is disappointing. It means that those worries have been handled for you and you don't care to learn them En contraire. The problem is that some years ago I did learn the basics, but the ground has shifted underneath my feet multiple times. There's not really an incentive to learn the finer points of ESM-vs-CJS if Typescript hides the input into the system, Angular has its own ideas about modules, uses Webpack or babel internally and then spits out CJS anyway. The whole JS ecosystem is nice if you edit 10 files by hand, but I just don't know what I should do with the knowledge that I should "require cjs" when I need Typescript for type safety and it'll only let me "import ts" anyway.