Using ESM for Vite HMR always causes memory leak in browser

[naruaway]

Hello! I love using Vite, especially its snappy behavior of dev server.

Recently I (re)discovered that Vite is using ESM for HMR (Hot Module Reloading: for React, Fast Refresh is used), where it calls dynamic import like import('http://localhost:5174/src/App.jsx?t=' + Math.random()) internally for every file modification. And this causes memory leak as seen in the following example:

// For more details: https://github.com/naruaway-sandbox/fast-refresh-hmr-memory-leak-demo
const DATA = Array.from({ length: 100000 }, (_, i) => Math.random());

// This "App" holds a reference to "DATA" via closure
export const App = () => {
  return (
    <div>
      <div>REWRITE_HERE</div>
      <div>{DATA.length}</div>
    </div>
  );
};

Since there is no way to purge the module record for ESM, every exported thing will never be purged, which means if this App.jsx is generating heavy data, changing App.jsx quickly ends up in huge memory usage. Historically the same issue has existed for Snowpack (I could not find the exact issue although I remember there was some discussion about memory leak for Snowpack)

For webpack / Next.js, since they do not use ESM, I was able to eliminate the memory leak by fixing react refresh utils, which was unnecessarily holding previous exports by themselves. However, for Vite, even if I fix react refresh utils, memory leak will still remain since ESM record will hold exports forever.

I created a repro with more detailed explanation in https://github.com/naruaway-sandbox/fast-refresh-hmr-memory-leak-demo (this includes links to fixes for Next.js and @pmmmwh/react-refresh-webpack-plugin)

I would like to discuss with the community / core contributors whether it's feasible to consider different ways to load new code for HMR without using ESM. I can also imagine some ways to mitigate leaks by replacing ESM exports with dedicated mechanism though.

Also, I am interested to hear whether this issue is worth solving or not. For my specific case, I was prototyping some GUI authoring tool, which directly modifies source files in real time and realized that every change accumulates RAM usage. So at least I think eliminating memory leak here could stabilize this kind of use case for Vite.

I also imagine some people working on heavy SPA might be already suffering from heavy RAM usage without noticing the root cause.

[bluwy]

I don't think there's much Vite can do with this at the moment. It lives and breathes ESM, and it can't switch to another way to mitigate that. But if I'm not mistaken, the unused ESM modules could still be garbage collected though so the RAM isn't limited to the stale modules. Until then, we'd need the ESM spec to support invalidating them to address this.

[naruaway]

the unused ESM modules could still be garbage collected though so the RAM isn't limited to the stale modules.

I think in the current ESM spec, browsers can never purge exported objects from a module since it cannot know whether the same module will be imported later or not. If the same URL was used later (e.g. it might be "24 hours later" as long as the browser tab is not closed), browsers need to return the cached one. So garbage collection will never work here.

I was thinking we might be able to use different mechanism only for HMR like "script (not ESM) + dynamic import" but if we need to stick with ESM as a code loading mechanism of HMR, we definitely need an ESM spec to support invalidation

And unfortunately, I could not find such ESM spec. Node.js also has the same issue and they have this open (as of 2023-10-09) issue nodejs/node#49442

For server side, I believe vite.ssrLoadModule is not using Node.js ESM implementation under the hood so there is no memory leak though

[bluwy]

Thanks for the explanation. Yeah in that case we would have to wait for the spec to support it then. Maybe it's also worth auditing HMR and see if there's any optimizations can be done to reduce module loading.

And yeah SSR is a lot more hands on to provide HMR that Vite controls module loading (and removing).