Subject: JS0/JSSugar; converting CommonJS to ESM; top-level await in Node.js; Node.js v23.0.0; Bun v1.1.31; ESLint v9.13.0; Turborepo 2.2

We linked to the JS0/JSSugar slides in last week’s issue. We now have reactions to those slides. It’s important to keep in mind that it’s not even a proposal yet, just first thoughts about a topic. One point in particular strikes me as worthy of discussion: What does it mean for the JavaScript ecosystem if so much of the code is compiled (Babel, TypeScript, bundling, etc.)?

The blog post “New TC39 proposal! Does JavaScript require a compiler soon?” by Nils Riedemann has a mostly positive take on JS0/JSSugar: “It will also help to prevent further language bloat; like I’d love pipes in JS, but since that proposal doesn’t seem to get anywhere, it might be better suited for JSSugar as they can easily be transpiled to JS we have today. Immutable Data Structures (Records/Tuples), however, those would be features of JS0 so that browser engines can optimize memory handling.”

The blog post “JS0/JSSugar: the tooling will continue until morale improves” by Caolan McMahon is more critical: “Quote: ‘No evidence suggesting tooling use would decrease in future.’ I imagine if you work at Google, that is true. But I suspect most developers are not professionals working at a tech giant but hobbyists doing their best in a confounding ecosystem of tooling. If we give up on shipping their simple code directly to a browser, what hope have they of putting down those tools in future?”

You can now require() an ESM module in Node.js – but only if none of the modules it imports contain a top-level await (TLA). Thus, adding a TLA to an ESM module, breaks CommonJS modules that use it.

The blog post is critical of require(esm). However, given how much it helps with migrating libraries to ESM without breaking CommonJS code, I personally think the positives far outweigh the negatives.

[Quoting the blog post:] Key highlights include:

• Enabling require(esm) by default for Node.js applications
• Removing support for Windows 32-bit systems
• Stabilizing the node --run command
• Enhancements to the test runner, including glob pattern support for coverage files

• The predefined array of config objects used by ESLint can be now accessed programmatically as ESLint.defaultConfig.
• To speed up loading, the ESLint CLI will automatically enable V8’s code cache in newer versions of Node.js.
• Custom languages can now provide their default options with the defaultLanguageOptions property. See the documentation about the Language object.

• Repository queries [experimental]: Explore your repository like never before with turbo query.
• Improved cache safety: Easily diagnose and fix missing environment variable dependencies, and incorrect cache configurations
• Zero-configuration comparisons for affected packages: Automatically target packages with changes in GitHub workflows