esm
loader
esm | loader | |
---|---|---|
2 | 1 | |
5,252 | 0 | |
- | - | |
0.0 | 7.9 | |
8 months ago | 8 months ago | |
JavaScript | TypeScript | |
GNU General Public License v3.0 or later | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
esm
-
CommonJS Is Hurting JavaScript
> 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 that tiny tiny tiny corner case) interop via @standard-things/esm, which seamlessly let the two worlds interop. It'd been around for years before node started shipping support, and it was no ceremony just works bidirectional interoperability, and it took basically no effort or thought from the developers point of view to use. It sucked seeing us walk back from great, mired by frivolous over concern for a obscure corner-case.
https://github.com/standard-things/esm
-
ERR_REQUIRE_ESM
2) Stay on ES5. Wrap ES6 module(s) with esm adapter. Just like the documentation says:
loader
-
CommonJS Is Hurting JavaScript
Your first point is absolutely spot-on but I am curious as to how much treeshaking was on the minds of masses at the time. The tooling of that era didn't really have any good support for tree shaking even for non-AMD includes and it was quite experimental tech (as in, I don't think it was a decision making factor for the majority of the tools on the scene).
The second point actually isn't strictly valid. I've written my own "all-in-one" async custom loader [0] that can require() CommonJS/AMD includes or regular "add a script tag" includes w/out any exports, all asynchronously, with asynchronous dependency trees for each async dependency in turn. You can define in the HTML source code a "source map" that maps each dependency name to a specific URL, so that you don't need knowledge of the filesystem tree to load dependencies.
Ideally, this source map can be generated via the tooling you use to compile the code (e.g. `tsc` is aware of the path to each dependency) but I haven't written my own tool to generate the require path to url map.
[0]: https://github.com/mqudsi/loader
What are some alternatives?
hello-esm-firebase - 🔥 ESM in Cloud Functions (via Firebase)
webpack-common-shake - CommonJS Tree Shaker plugin for WebPack
semantic-release - :package::rocket: Fully automated version management and package publishing
meta - Meta discussions and unicorns. Not necessarily in that order.
webpack - A bundler for javascript and friends. Packs many modules into a few bundled assets. Code Splitting allows for loading parts of the application on demand. Through "loaders", modules can be CommonJs, AMD, ES6 modules, CSS, Images, JSON, Coffeescript, LESS, ... and your custom stuff.
oletus - Minimal ECMAScript Module test runner
nanoexpress - Professional backend framework for Node.js
node - Node.js JavaScript runtime ✨🐢🚀✨
alameda - AMD loader, like requirejs, but with promises and for modern browsers
base64-transcode - Base64 encoding and decoding for both browser and node, with binary file support.