💾 Archived View for jb55.com › ward.asia.wiki.org › javascript-modules captured on 2021-12-04 at 18:04:22. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
In the most ubiquitous programming ecosystem, modules have been shoehorned in where they were originally lacking. As of early 2018, nodejs gradually builds toward ECMAScript Modules. Guidance for transition from CommonJS to ESM: link
The whole thing is complicated by the fact that ES Module loading is asynchronous in nature, while CommonJS is synchronous by nature.
Lots of code out there in the wild uses ES Modules as specified by babel/webpack, but which is different from the final way. Why different? Because babel/webpack load ES Modules synchronously, while the specification of ES Modules specify _asynchronous_ loading.
NPM is the largest package repository in the world:
<div style=" padding: 12px; background:#eee; width:96%; align=centered;"> <img style=" display:block; margin:auto; width:100%;" src="https://cdn-images-1.medium.com/max/1600/1*C_m4eORezKNi-IAIgbxdLg.png"> <p class=caption> Transported image. source </p> <p class=caption> Data. source </p> </div>
There's also a status report from Node.js Technical Steering Committee. It reads as an example of argument mapping with areas of agreement identified along with areas still unresolved. link
Someday this will be nice: "We are committed to having the Node.js and Web platform as first class runtimes for modules. Modules installed via npm should be able to run after installation without requiring a build step."
Will wiki need to adopt ECMAScript Module conventions? I think `grunt` and `browserify` produce CommonJS-style behavior. Will we need to adopt different build tools?