Move on to ESM-Only

They key thing is that require(esm) shipped in node 22, and is being back ported to node 20.<p>Since Node 18 maintenance ends in less than a month, this means all Node versions will have good esm support, including for consuming esm-only libraries (which until recently did not work!)<p>This is noted somewhat in the article, but basically is the whole story to me. Its now <i>possible</i> to stop doing CJS libraries entirely. And with that, I don&#x27;t see why we would do CJS at all.

Huh, oddly no mention of native browser support in the form of &lt;script type=“module”&gt; and importmaps! To me, that felt like the last platform to offer ESM support.<p>I also feel like browser support “feels” more official than support from bundlers.<p>Just weird to leave out a mention of that.

On a side note, I recently experimented with native TS support in Node.js and it felt like magic: no need for extra flags; debugging and watch just work; types are simple to re-use between browser and server. Erasable syntax seems like the way forward, can&#x27;t wait for it to land in browsers.

<i>&gt; The Toolings are Ready</i><p><i>&gt; Modern Tools</i><p><i>&gt; With the rise of Vite as a popular modern frontend build tool, many meta-frameworks like Nuxt, SvelteKit, Astro, SolidStart, Remix, Storybook, Redwood, and many others are all built on top of Vite nowadays, that treating ESM as a first-class citizen.</i><p><i>&gt; As a complement, we have also testing library Vitest, which was designed for ESM from the day one with powerful module mocking capability and efficient fine-grain caching support.</i><p><i>&gt; CLI tools like tsx and jiti offer a seamless experience for running TypeScript and ESM code without requiring additional configuration. This simplifies the development process and reduces the overhead associated with setting up a project to use ESM.</i><p><i>&gt; Other tools, for example, ESLint, in the recent v9.0, introduced a new flat config system that enables native ESM support with eslint.config.mjs, even in CJS projects.</i><p>I think the author and I must have very different definitions for the word &quot;ready&quot;

I was working on a legacy CSJ project, and I tried to upgrade an OIDC library, but the newer version would only work with ESM. I decided to use that as an excuse to migrate our project to ESM. However, I hit a bug using dd-trace with ESM. Over a year later, that bug hasn&#x27;t been resolved. I try to use ESM as much as possible for new projects, but it&#x27;s not always simple to migrate existing projects to ESM.

Meanwhile I&#x27;m trying to adapt ESM only packages to CJS since Goja (JS runtime library for Go) doesn&#x27;t have ESM support. [1]<p>And yes I know that Grafana has a fork called Sobek that has ESM support, but it is tailored for k6 and they don&#x27;t have plans for making it easier to use. [2]<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;dop251&#x2F;goja&#x2F;issues&#x2F;348" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;dop251&#x2F;goja&#x2F;issues&#x2F;348</a><p>[2] <a href="https:&#x2F;&#x2F;github.com&#x2F;grafana&#x2F;sobek&#x2F;issues&#x2F;49" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;grafana&#x2F;sobek&#x2F;issues&#x2F;49</a>

Did anyone make a large TypeScript codebase work with ESM + TS + node (together with IDE support and yarn pnp support?)<p>The thing that is annoying with ESM is that it requires to have extensions in imports, i.e. `import .. from &#x27;&#x2F;foo.js&#x27;`.<p>This gets messy with TypeScript, where your files are named `foo.ts` but you need to import `foo.js`.<p>The previous &quot;best practice&quot; in TS world was to have extensionless JS imports, so this move would require a massive codemod to update all imports in an entire codebase.<p>For now, we&#x27;ve been using `ts-node` with swc under the hood, but without ESM. I tried `tsx`, but the compilation time of esbuild is way too slow, some of our node CLI tools written in TS take 15s to boot up, which is not acceptable (with `ts-node` it&#x27;s 3-4s) (tbh, it&#x27;s probably partly a fault of our CLI framework, which crawls all workspaces to discover all CLI tools, and as we have a lot of them, tsx has a lot of useless work to do).

In my experience, the biggest obstacle to ESM in production systems is every observability&#x2F;tracing tool relies on require-in-the-middle or in some other form CJS require().

The way this cutover is being handled is reminiscent of Python 2-&gt;3. To this day, I still run into compatibility issues between things that only work with ESM and things that only work with CJS. It&#x27;s frustrating, to say the least.

&gt; Although a significant portion of packages still use CJS, the trend clearly shows a good shift towards ESM.<p>Does it?<p>The chart being used in the opening argument is far from compelling. When I hold my phone sideways, it looks as though the ESM portion is plateauing or feebly (at best) increasing. Maybe by 2040 we’d see widespread ESM adoption?<p>Jokes aside, I prefer ESM (and would prefer if everyone else preferred it), but leading with adoption rates is weak sauce.

All these new bundling libraries (vite&#x2F;rollup) always claim to just work, chefs kiss, 100 emote. And then you actually try to use them for basic use cases and you find yourself googling or knee deep in the documentation. If at all possible I try to avoid bundling libs altogether. That&#x27;s the future I want. No more vite or rollup or webpack.

VS Code still doesn&#x27;t support ESM in extensions, you have to transpile to CJS.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;vscode&#x2F;issues&#x2F;130367" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;vscode&#x2F;issues&#x2F;130367</a>

I&#x27;ve been ESM only for the last 2 years and it has been amazing. Now to be fair, I am doing it on new projects so that probably simplifies things, but it is very freeing and performant.

The main problem with es modules is mocking in tests. How do people work around that issue?

I am surprised they still use outdated syntax when there is a standard for modules. Also, it is much better when you specify full path to the file and do not have to remember the resolving rules.<p>Also, last time I tried to use ESM in a browser with Vue and unpkg without builders and web server, it didn&#x27;t work (probably because one cannot import modules from a local folder). I wish support for ESM and localhost was improved also. I don&#x27;t want to use a webserver or a bundler because it is easier without them so I switched to legacy scripts without modules.

To achieve an ESM-only future, we can&#x27;t have features that only work in non-ESM. Browsers don&#x27;t support synchronous blocking loading and execution of ESM scripts.

ECMAScript modules

Any kind of migration breaks code. Every single line of <i>practical</i> code hit by a breaking change should be considered a bug. Before the security theater takes the stage, let me clarify by saying that I don&#x27;t mean we should not have breaking changes at all, but that only by explicitly treating them as serious bugs, can we even hope to set up a process to minimize them. Of course, the minimization objective will have multiple other variables -- security being one of them.<p>Therefore, when it is possible to not break <i>practical</i> code, it should not be done. This is the &quot;linux philosophy&quot;, if you will. Among JS runtimes, Bun is a great example. In bun today, you can, in the <i>same file</i> (!!), with zero code changes, 100% transparently:<p>1. require() a module regardless of whether it is cjs or esm [1]<p>2. <i>synchronously</i> `import` a module regardless of whether it is cjs or esm.<p>3. do either of this with typescript or javascript<p>Some of these required changes in JavascriptCore, which were implemented - it&#x27;s good to see a lack of cribbing about &quot;it needs to be supported in upstream&quot; and a focus on practical end-user usage.<p>Any runtime&#x2F;kernel that doesn&#x27;t put this level of effort into not breaking code is just not serious. While Node is at least moving in the right direction, supporting require(esm) with some restrictions, Deno is completely hopeless - CJS code is completely unusable on Deno. The reasoning is crazy too - how does it matter if ESM is the &quot;standard&quot;, if millions of lines of practical, real world code is using CJS? It does not matter that popular libraries move to ESM. Even a single internal tool that&#x27;s locked into CJS for some reason means that a project cannot move away from it easily. Then like someone mentioned below, many &quot;plugin architectures&quot; and &quot;command architectures&quot; are pretty much locked in to require(). The whole Deno project screams &quot;ideology &gt; pragmatism&quot;. Hopefully, just like they came to their senses w.r.t node compat [2], they implement CJS interop as well.<p>[1] You cannot require() an ESM module that uses top level await<p>[2] In contrast, bun&#x27;s node compat story is very good, they run the Node.js test suite on every commit to Bun, and pass a huge majority of the test cases. Track the progress here: <a href="https:&#x2F;&#x2F;bun.sh&#x2F;docs&#x2F;runtime&#x2F;nodejs-apis" rel="nofollow">https:&#x2F;&#x2F;bun.sh&#x2F;docs&#x2F;runtime&#x2F;nodejs-apis</a><p>There is even some effort put into V8 APIs(in a JSC runtime!!). This helps with using Bun with the usual debugger in the chrome browser&#x2F;VSCode, modules that use `node:v8`, etc,. Read about it here: <a href="https:&#x2F;&#x2F;bun.sh&#x2F;blog&#x2F;how-bun-supports-v8-apis-without-using-v8-part-1" rel="nofollow">https:&#x2F;&#x2F;bun.sh&#x2F;blog&#x2F;how-bun-supports-v8-apis-without-using-v...</a><p>There is also compat the <i>other way</i> - there are the beginnings of node&#x2F;browser polyfills for Bun-only APIs: <a href="https:&#x2F;&#x2F;github.com&#x2F;oven-sh&#x2F;bun&#x2F;tree&#x2F;main&#x2F;packages&#x2F;bun-polyfills" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;oven-sh&#x2F;bun&#x2F;tree&#x2F;main&#x2F;packages&#x2F;bun-polyfi...</a>