esm
meta
esm | meta | |
---|---|---|
2 | 5 | |
5,252 | 113 | |
- | - | |
0.0 | 0.0 | |
8 months ago | over 3 years ago | |
JavaScript | ||
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:
meta
-
CommonJS Is Hurting JavaScript
> You write this as if that mattered... Should he only works on stuff that gets more download?
It was a statement of fact. You appear to be drawing conclusions that were never hinted at nor implied. It's tiresome.
> It's normal to be sad to have lost someone that was working on something you needed, but anything else is just entitlement.
How and why are you applying entitlement and emotion to a documented statement of fact? Do you need to see links such as [1] to view that as fact? It's one of a myriad. Take your asinine analysis and commentary elsewhere, please.
[1] https://github.com/sindresorhus/meta/discussions/15
-
Today’s JavaScript, from an outsider’s perspective (2020)
ESM is the biggest waste of time in the JS ecosystem. People are trying to move thing to ESM before it's even in a stable enough state. Mixing ESM and commonjs is a PITA. I've been a JS-only dev since 2013, and I've had enough of ESM ideologues.
See https://github.com/sindresorhus/meta/discussions/15 for just ONE example of this mess.
I don't know why it's become this ideological war where people are 'testing the waters' on production-used libraries. It's not the approach I would have taken.
- It's a community splitting decision, like Python 3 vs 2.7, which has been an on-going battle for over a decade, I wouldn't be surprised to see the same happen here unless changes are made.
-
My collection of helpful Utility Types :D
Also here's some reading for you by people that are saying the same thing I am: - The dude that wrote half of npm: https://github.com/sindresorhus/meta/discussions/7 - The guy who wrote "JavaScript the Good Parts": https://www.youtube.com/watch?v=PSGEjv3Tqo0&feature=youtu.be&t=9m21s
What are some alternatives?
hello-esm-firebase - 🔥 ESM in Cloud Functions (via Firebase)
packj - Packj stops :zap: Solarwinds-, ESLint-, and PyTorch-like attacks by flagging malicious/vulnerable open-source dependencies ("weak links") in your software supply-chain
semantic-release - :package::rocket: Fully automated version management and package publishing
tetra - Tetra - A full stack component framework for Django using Alpine.js
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.
paperclips - Universal Paperclips mirror
oletus - Minimal ECMAScript Module test runner
node-fetch - A light-weight module that brings the Fetch API to Node.js
nanoexpress - Professional backend framework for Node.js
.NET Runtime - .NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
node - Node.js JavaScript runtime ✨🐢🚀✨
utility-types - Collection of utility types, complementing TypeScript built-in mapped types and aliases (think "lodash" for static types).