3 ms·

As of now, I still don't know what we got from this switch to ESM. It's a terrible breaking change which in some cases make it impossible to upgrade packages, u

As of now, I still don't know what we got from this switch to ESM. It's a terrible breaking change which in some cases make it impossible to upgrade packages, unless you convert you whole codebase first which in many cases is not possible. What's the benefit is unclear. Maybe we don't need a build step anymore for the browser? But not really - for any project of a significant size, sooner or later a build step will be needed for this or something else. Not to mention that many projects are now done in TypeScript, which means there's a build step anyway. For me it sounds like an influential npm developer got this idea that we should avoid a Python 3 situation and decided to force everybody right now to switch to ESM. He maintains enough npm packages to be able to force this and he did. Now we are in this situation where numerous codebases are stuck with certain pre-ESM packages, and there's very little we can do about it.

its-summertime 3y ago
> But not really - for any project of a significant size, sooner or later a build step will be needed for this or something else. Not to mention that many projects are now done in TypeScript, which means there's a build step anyway. https://github.com/sveltejs/svelte/pull/8569 https://github.com/sveltejs/svelte/pull/8569 > As a Svelte compiler developer, debugging without a build step greatly simplifies compiler development. Previously, debugging was complicated by the fact that we had to debug using the build step. In addition, using JSDoc does not affect compiler’s development safety because the type is almost equivalent to TS. Deno also switched away from using build-requiring TS
- zdragnar 3y ago
  Funny, since both svelte and deno are runtimes that require compile steps for user code before passing the code to the JS engine (svelte itself is a compiler, deno still has to compile typescript for V8 to run). Neither of these projects are trying to pipe thousands of files to a browser, which is what OP was talking about, I suspect. HTTP2 is better than 1 in this regard but not good enough that most people abandoned bundling.
- kesor 3y ago
  Even if you use Typescript to build your .ts into .js, in a case of very small scripts in Node.js you now also cannot use new-er versions of your dependencies because one of the dependencies happened to move from CommonJS to ESM. Every short script you ever develop will require ALL of its dependencies be either one, or the other, or the third option - which is setup a hugely complex bundler system to somehow make sense of what to do with the different types of code by rewriting it.

its-summertime 3y ago

> But not really - for any project of a significant size, sooner or later a build step will be needed for this or something else. Not to mention that many projects are now done in TypeScript, which means there's a build step anyway. https://github.com/sveltejs/svelte/pull/8569 https://github.com/sveltejs/svelte/pull/8569 > As a Svelte compiler developer, debugging without a build step greatly simplifies compiler development. Previously, debugging was complicated by the fact that we had to debug using the build step. In addition, using JSDoc does not affect compiler’s development safety because the type is almost equivalent to TS. Deno also switched away from using build-requiring TS

zdragnar 3y ago
Funny, since both svelte and deno are runtimes that require compile steps for user code before passing the code to the JS engine (svelte itself is a compiler, deno still has to compile typescript for V8 to run). Neither of these projects are trying to pipe thousands of files to a browser, which is what OP was talking about, I suspect. HTTP2 is better than 1 in this regard but not good enough that most people abandoned bundling.
kesor 3y ago
Even if you use Typescript to build your .ts into .js, in a case of very small scripts in Node.js you now also cannot use new-er versions of your dependencies because one of the dependencies happened to move from CommonJS to ESM. Every short script you ever develop will require ALL of its dependencies be either one, or the other, or the third option - which is setup a hugely complex bundler system to somehow make sense of what to do with the different types of code by rewriting it.