You wouldn’t, because it’s a misunderstanding of what “module” means and how they work. It’s like saying “maybe I need this file” - there is no maybe, you either need it (to run conditional logic upon) or you don’t.
You get an approximation of conditionally loading a module by simply converting everything to ESM and enabling tree-shaking. When module loading has no side effects this is simple to do. If you’re unsure at build time whether you will call a certain function from a certain module and that’s the reason you’re conditionally loading it, again enable ESM and tree shaking and import the function and call it conditionally except do so at runtime. You’ll only get exactly what you need to avoid the bloat of the whole module and your dependency graph will also be more correct as a bonus!
I've been a full time NodeJS programmer for fourteen years. Module isn't some pure theoretical concept. It is a file that exports something in Node.
There's a ton of 'maybe I need this file' in the world. For example, I have things that are polymorphic by instance. I grab a config entry to decide which of several modules are going to be used. The others are completely unnecessary.
You might say, just add a build step that chooses the right ones. To which I would say, Are you nuts? Why would I screw up a perfectly working paradigm?
To get "an approximation of conditionally loading".
As a matter of fact _module_ is a pure theoretical concept. The fact that we’re discussing at least two different implementations of modules alone proves that it’s at least more abstract than _file_. It’s certainly not strictly related to Node, plenty of languages (and their associated runtimes, if applicable) have modules. Further, it wouldn’t matter what a specific implementation of modules within Node is, nor would 14 years of experience with Node.
You’re missing the point entirely, perhaps intentionally? If you’re using modules you’re already using a “build step” - code that runs before your actual code. Your “perfectly working paradigm” is only such if you intentionally disregard the core reason for modules: modularity.
My assertion is that, having been made aware of the pitfalls of effectful imports, continuing to argue for using them requires a willful misunderstanding.
People outside the context of this discussion could simply be uninformed, they don’t need to be willfully misunderstanding.
No. It is a result of a practical, engineering perspective. I love theory. It's necessary for moving the world forward.
I also love getting things to work. Three quarters of NPM packages are CJS. Several of them are ones I wrote.
The reason they are not ESM is that the theoretically pure folks had control and I voted with my fingers because everything I do has to fit in my a substantial amount of existing CJS code.
Arguing for practical solutions that accommodate an imperfect world is absolutely correct.
For good measure, it is an operation that executes by the runtime for every execution, not as a redeployment.
Turns out that the ESM purists struggle to find reasons to condemn those of us who don’t have the need or resources to the chase bleeding edge of purity.
You get an approximation of conditionally loading a module by simply converting everything to ESM and enabling tree-shaking. When module loading has no side effects this is simple to do. If you’re unsure at build time whether you will call a certain function from a certain module and that’s the reason you’re conditionally loading it, again enable ESM and tree shaking and import the function and call it conditionally except do so at runtime. You’ll only get exactly what you need to avoid the bloat of the whole module and your dependency graph will also be more correct as a bonus!