esm

Before Node had any/experimental module support (April 2019, https://nodejs.medium.com/announcing-a-new-experimental-modu...), I'd been using std-things/esm loader for Node.js, which seemed to have no problem allowing CJS and ESM to interop, require and import each other. In my experience it worked flawlessly. https://github.com/standard-things/esm It's wild to think about: esm has taken nearly a decade to be feasible for folks to use, without heavy encumbrance; it was the key feature of es-2015/es6! It took many more years for import-maps to become a thing, such that we could start using modules in a modular fashion; we've had to use bundlers/codemods to re-resplve dependencies, unless you've been going to go Deno's original path of just hitting absolute urls wherever they be. There's still no standing proposal for how we get import-maps

It's all just so extra crazy because https://github.com/standard-things/esm has just worked for so so long. The intense module discussions kept happening, about why it wouldn't work or how it would blow up, but standard-things/esm was already out & working great.

> I think the biggest miss was not making mixed mode (default) for Node do it the way webpack/babel, etc did it by default in terms of interop. I get they wanted to make it more implicit to call cjs from esm, in the end it just inhibits conversion of existing libraries as dependencies are now a bigger hurdle. Huge huge agreement. I forget the specifics but there was some super tiny corner case around maybe default exports that could potentially create ambiguity & that spawned a multi-year bellyaching around doing anything at all for interop. What Node got was incredibly hard fought for against much resistance to interop. But the final compromises made everything so much more painful for everyone. So many esm projects but oh look a .eslintrc.cjs, how unsurprising & sad. It's extra maddening because node had a wonderful just works (except t

It is possible, but you have to hack the Node require() loader to do it, teach it a lot about ESM loading, and then hope the downstream CJS don't have timing bugs around "very long" synchronous require() loads. https://github.com/standard-things/esm

Wait till you throw a package.json with "type": "module" in there. Everything used to work until Node 12.15, then 12.16 started throwing when trying to require type:module packages with `require` (which is what `esm` does) https://github.com/standard-things/esm/issues/868

You can use ESM (including dynamic import) in node 6+ (without babel) by using https://github.com/standard-things/esm and cut the `.mjs` and "it can't work like that" crap.

Indeed, JS does not have classical inheritance. IMO introducing a class syntax that looks so much like the classes from other languages and yet behaves differently was a mistake. The rest of your comment sounds a bit misinformed to me. You seem to have decided that prototypical inheritance is somehow inherently worse than classical inheritance, but don't mention why that would be. I have found very little practical difference between the classes in JS and other languages in everyday use, and can't quite imagine what the problems with it might be. Furthermore, ES6 (ES2015) is not a "transpiled language". I think it's obvious that if you take a very new language, say, ES2018 and want to run it on your toaster that doesn't have support for such new languages, you are going to have to do some kind of precompilation step. That is true for ES20

I know styfle is aware, but for others, you can unlock named exports of CJS modules with @std/esm: https://github.com/standard-things/esm https://medium.com/web-on-the-edge/es-modules-in-node-today-...