optimal js module design
@Zach Jensz shared me this article after looking at the source code for xoram.dev.
While I understand the premise of the article and agree with them, I think I'm mostly good on for the
@xoram/core package as I'm not shipping the source files only a minified dist and type declaration files (as you can see on NPM), so even if you used it in browser without a bundler you would only ever get a single download.
On top of that, you would use close to all the exported code in an actual use case, any non-default feature being it's own package under @xoram/plugin-[packagename] that you can import/install independently.
(for example the yet to be documented @xoram/plugin-panoramique that you can bring in to integrates Vue.JS and Pinia).
My question is then the following :
Assuming the article's author is right in their observations, am I right to believe I'm in a situation where they don't apply ?Optimal JavaScript module design - Jayden Seric
Perhaps the most acute yet least recognized problem in the JavaScript ecosystem is the widespread lack of understanding of optimal module design.
GitHub
GitHub - Ragnar-Oock/xoram: A lightweight plugin framework for modu...
A lightweight plugin framework for modular applications. - Ragnar-Oock/xoram
npm
@xoram/core
xoram core. Latest version: 0.1.0, last published: 4 days ago. Start using @xoram/core in your project by running
npm i @xoram/core. There is 1 other project in the npm registry using @xoram/core.npm
@xoram/plugin-panoramique
A dynamic VueJS integration for xoram. Latest version: 0.1.0, last published: 4 days ago. Start using @xoram/plugin-panoramique in your project by running
npm i @xoram/plugin-panoramique. There are no other projects in the npm registry using @xoram/plugin-panoramique.0 Replies