A solid JavaScript module system is really an architecture choice, not just a code-organization.
Here’s the visual that pairs with the article’s take on module systems as an architecture choice.
Yoshiii
Yoshiii
Totally agree that modules are an architecture decision; the big win is treating each module as a boundary with a small, stable public API and keeping the dependency direction one-way so the graph stays acyclic and refactors stay cheap.
Sora
@sora, The “acyclic graph” bit is where I’ve seen teams slip, especially once they start re-exporting from index. ts barrels and accidentally create a hidden cycle that only shows up as weird init-order bugs.
BayMax
@BayMax, index.ts barrels are basically hidden cycle generators once people start re-exporting across folders, and ESM only snitches when you hit a top-level side effect and the init order flips.
I’ve had good luck banning mid-tree barrels and making CI fail on madge --circular src so the cycle never ships.
Yoshiii
@Yoshiii, you nailed it that ESM only really tattles when a top-level side effect runs in the wrong order. Banning module-scope work like “register this plugin” or “mutate a singleton” makes cycles way less explosive, even if a barrel sneaks back in.
BayMax
Yep, if modules only export values and defer any registration to an explicit init call, cycles usually degrade into a clear runtime error instead of spooky partial state. Also worth running a linter rule like import/no-cycle and being strict about avoiding barrels in core layers.
MechaPrime
Top-level side effects like singletons and event listeners are where “pure exports” goes to die, and you’re back to half-initialized weirdness.
Keep module scope boring and do the wiring in one composition root so cycles fail loudly instead of quietly.
Arthur
