It sucks that #SkyPack didn't catch on.

https://docs.skypack.dev/

#unpopularOpinion ESModules over HTTP are fine and the web doesn't need a bundler or a package manager registry.

If you’re running a relatively recent version of Node.js – I’m on 22.x for Kitten¹ at the moment– and you use ES Modules (because, of course, you use ES Modules, right, because it’s almost 2025…) and you want to use .js extensions and not have to litter package.json files with "type": "module" all over the place, you can start Node with the following flag and it should Just Work™ ;)

--experimental-default-type

¹ https://kitten.small-web.org

I don't want to publish to #NPM because that organization has been shitty for a decade now.

#JSR seems like more of the same.

Why didn't #HTTP based #ESM #packageManagement catch on? #JSR says it's because you can't do #semvar, but I don't see why not; just use file paths ("example.com/package/major/minor/patch/")

I don't see an advantage to publishing #modules to a #package #registry at this time.

I wrote: "In the future using top-level await might be a BC break in Node". Read it here:

https://evertpot.com/using-top-level-await-is-bc-break/

Want to know why #CommonJS was a mistake?
One phrase. Conditional #module #exports.

if (condition) {
module.exports = foo
} else {
module.exports = bar
}

It's 2024; #JavaScript #libraries should be shipping #ESModules *only*

99 dependencies and they're all @eslint

Guess which version switched to ESM-only? #javascript #esm

Is it wrong if I'm kind of enjoying the drama about #ljharb?
Burn tc39 down! Make the web anew!
The only standard is death comes to everything!

> enough libraries use ES Modules that for many projects you need to either use ES Modules, or figure out how to interoperate ES Modules with your CommonJS code. At the same time, enough code still uses CommonJS that you often need to figure out how to include that legacy code in your otherwise-ES Module project.

https://borischerny.com/javascript,/typescript/2024/06/19/ES-Modules-Are-A-Mess.html

> Babel has stayed on CJS until now because that allows deferring loading modules until they’re needed for performance: While that’s possible with ESM, it has much worse ergonomics.

https://thenewstack.io/how-javascript-is-finally-improving-the-module-experience/

> The recent update in Node.js introduces an experimental feature that allows require() to synchronously load ESM graphs that do not contain top-level await. This feature is significant because it allows developers to use require() with ESM.

https://zacharylee.substack.com/p/native-support-for-cjsesm-interoperability

> Support for require()ing ESM graphs is now exposed by default in Node.js 22

https://openjsf.org/blog/nodejs-22-available