A library ten times bigger, and renders that tidy up

Every motion template is a small React component with its own description of the fields it accepts. Adding 664 of them gave TypeScript hundreds of new shapes to check, and the build hundreds of new files to compile.

That is a good problem: it means the product got richer. But tools come with default limits, and Node gives each process a set amount of working memory unless told otherwise. Our type check and our production build had simply grown past that amount. Our releases only go out once every check has passed, so the new library waited at that gate until the checks could finish.

The easy move would have been to raise Node's memory everywhere. We chose not to, because the web service that answers your requests has its own limit, and a bigger allowance there would only hide a slow leak one day.

So the extra room goes to exactly three places:

• the type check carries its own, larger allowance;
• the automated checks that run before every release set it for their steps;
• the image build raises it for the build command alone, so the service that runs afterwards is unchanged.

With that, the checks passed and the motion bank went out the same day. We also added a habit: when a library grows by hundreds of files, measure the build's memory before the release, not after.

The second piece of work was about disk space. Before Remotion draws a film, it packs the film's code into a bundle, a single folder the renderer reads from. That folder is about 0.9 GB, it lands in the system's temporary directory, and nothing removes it when the work is done.

Where our films are made, this never matters. Each render runs in its own short-lived job, and when the job ends, its disk goes with it. On long-lived machines, though, every bundle stays. Checking 664 templates in three shapes meant many renders in one day on our own development machine, and the folders added up quickly: 657 of them, about 42 GB.

We wanted a render that leaves nothing behind, wherever it runs. So we wrote a small helper, cleanupBundleOnExit, and wrapped every call to the bundler with it, in the render code and in every script that bundles.

• It runs on a normal finish, on an explicit exit, and on Ctrl-C or a stop signal.
• It only removes a folder named like a Remotion bundle, sitting directly in the temporary directory, so it can never touch anything else.
• A dedicated test checks that every place that bundles uses it.

We deliberately did not write a sweeper that empties the whole temporary directory on a timer. That folder is shared with every other program on the machine, and a tool that deletes by pattern in a shared place is exactly the kind that one day deletes the wrong thing. Each process now tidies only what it created, nothing more.

You will not see any of this directly, and that is the point. The designed cards arrived in the product on the day they were ready, and the machines that check every template and every film keep the room they need to do it again tomorrow.

It also means we can keep growing the library. Each new batch of templates now comes with two questions answered in advance: does the build have the memory for it, and does every render clean up after itself. Both have a test.

Neither change was about a mistake in our logic. Both came from scale: a library that grows by hundreds of components changes the memory a build needs and the disk a render leaves. A code review will not show either; a measurement will.

So we now treat a big jump in content the way we treat a new feature: we measure what it costs the machinery, give it room precisely where it needs it, and make sure anything that writes temporary files also removes them.