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.
@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).