New blog post: Cache busting in Node.js dynamic ESM imports
(Includes link to a tiny module I made that generalises this that you probably don’t even need to use: https://www.npmjs.com/package/@small-tech/import-fresh)
@aral this is super funny as I was researching this exact issue and was writing up a response here, for updating 11ty (a static site generator) to work with ESM :))
This is an excellent reference, thank you for writing it up and now I can safely delete half of my work-in-progress comment 😂
@flakoot w00t! Very happy to hear it helped (and my condolences for your half comment. May it live forever happy in half-comment heaven).
@aral also fyi there's a follow-up conversation on the birdsite about this problem space that you might be interested in! https://twitter.com/slsoftworks/status/1363849035610796032
@aral This is a neat technique, but doesn't it potentially introduce a memory leak compared to the `delete require.cache` approach? I imagine Node is still caching the old versions of the module and they're never deleted. Probably a very tiny leak, but could matter if the module size is large and the cache is frequently busted.
BTW love your posts on ESM! I learn a lot reading these. 🙂
@aral That's really disappointing. It seems like something that should be solved at the spec level, since you might want to clear the cache in both Node and the browser.
@nolan @aral yeah the TL;DR seems to be (based on the conversation in https://twitter.com/davidmarkclem/status/1363882427521896449) is that a large chunk of (/almost all?) use cases seem to be around hot module replacement, and solving that issue specifically can solve the leakage without having to expose the cache.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!