Improving hot reload memory leaks

[parisholley]

I'll kick this off by saying, its a game of whack-a-mole hoping that any given npm module in your project is designed in a way to not behave terribly in an environment where delete require.cache is used. I've been trying to improve local development experience as much as possible and finally got tired of the dev server becoming unresponsive after so many requests.

Side note, anyone using class validator in their project should have this in their root.tsx:

// prevent memory leak
// @see https://github.com/MichalLytek/type-graphql/issues/580
delete globalThis['classValidatorMetadataStorage'];

After spending some time digging through the heap snapshots having narrowed down a few libraries/functions, what is left is effectively compiled code that is being kept around after each request. Presumably the memory references to this code can be just about anything (old timers, library code like orms, containers, etc).

I certainly see the benefits of "clean environments" per request but given the state of the npm ecosystem, there isn't a way a node process will stay alive during the course of the day after a lot of edits and reloads. Granted, it is a minor annoyance to have to kick the server after X minutes/hours, but I think the dev package could probably do things a bit different to solve for this.

Expire cache on change

I'd propose setting a process flag here to indicate source code has been updated:

remix/packages/remix-dev/compiler.ts

Lines 239 to 241 in ba5c848

	.on("change", async (file) => {
	if (onFileChanged) onFileChanged(file);
	await rebuildEverything();

Here check for that flag and only delete from cache if files have changed.

remix/packages/remix-dev/cli/commands.ts

Lines 299 to 301 in 8866ccd

	app.use((_, __, next) => {
	purgeAppRequireCache(config.serverBuildPath);
	next();

This could probably be a flag in remix.conf if there are cases where this delay is not ideal.

ESBuild multiple files

Because the entire project ends up compiling into a single js file, just a single dangling reference will keep the entire project in memory on every request/refresh. If the files were outputted individually (eg: like a tsc with emit output), we could perhaps hash diff the files and only purge what actually changed, reducing the footprint of source code kept around in memory. There could potentially be a trade-off in latency here, but may be worth it to keep memory down.

[kiliman]

I simply have a custom <LiveReload> component that first calls a special endpoint to purge, before refreshing the browser.

// LiveReload.tsx
if (event.type === 'RELOAD') {
  console.log('💿 Reloading window ...')
  fetch('/build/__purge__').finally(() => {
    window.location.reload()
  })
}

// server.js
app.use('/build/__purge__', (req, res) => {
  console.log('💿 Purging require cache')
  purgeRequireCache()
  return res.send('ok')
})

[parisholley]

@kiliman could you elaborate more on this code, not sure I follow

[kiliman]

I use the Express adapter, so I created a route to do the purge instead of having it run on every request. I copied the <LiveReload> component from Remix and edited it so it called the purge endpoint before refreshing the page. This results in only purging when Remix has rebuilt files on change.

If you're using Remix App Server, you'll need to switch to Express. I have a script that lets you eject from RAS to Express. https://rmx.fyi/ejectras