The current officially-sanctioned Node.js method of performing ESM hot module reloading is to (I kid you not) “leak memory.”
Je désespère!
@aral While I do think this is a real issue (and *yet another* reason why ESM is not a suitable replacement for CJS), it should be noted that hot-reloading modules is never a safe thing to do in JS regardless of the module system - the language does not provide sufficient state isolation guarantees to prevent state leaking between versions of modules, and this can lead to very strange non-reproducible bugs.
fuchsiaaaaaaaaaaaaaaaaa
@aral Oh yeah, sometimes you *do* actually need to clear the module cache for legitimate reasons, that's why I'm still seeing it as a deficiency in ESM. Just sharing the warning because this is something a lot of people aren't aware of, and most hot-reloading tools don't warn you about it :)
Personally I'm still stubbornly sticking with CJS and refusing to switch over to ESM, because of how broken and ill-designed ESM turned out to be - CJS is not going anywhere, too much of the ecosystem uses it and will never swap it out.
That having been said, I generally handle reload usecases by just restarting the process entirely (eg. via nodemon) or, in a browser context, LiveReloading the page; and working on some sort of (rudimentary) state persistence early in the development process.
It's a little more upfront work, but the resulting DX is honestly not that different from hot-reloading, and in the end I can trust the state to be consistent (ie. if I observe bugs, they are actually bugs, and not just a hot-reloading oddity).
@joepie91 Indeed. And yet needs must :)
That said, I’ve actually decided to try a far more pragmatic approach that I’m pretty sure will handle the 80% use case very well. And I plan on seeing how much closer I can get that to 100% over time.
Otherwise, you’re looking at either memory leaks, using workers, or – if you keep going down the rabbit hole (which I’ve done several times now) – recreating Node’s module system.