fix: memory leak in i18n builds

[SimonSiefke]

fix #10944

Details

Rspack keeps each custom chunk-asset runtime module's bound generator alive after compiler shutdown. Its compilation, chunk, and chunk graph references retain the complete compiler graph across localized builds.

Change

Track the current compilation's chunk-asset runtime modules and clear their compiler graph references during shutdown.

Before

When the fresh Docusaurus i18n build scenario runs six locale builds in one process, retained compiler hooks, stats, and MDX processors grow:

After

No more retained Docusaurus compiler graphs are detected.

Additional Info

• PR is AI-generated
• Model: Codex (GPT-5.6)
• Worktime: 1 hour, 14 minutes, 15 seconds

[netlify]

✅ [V2]

Built without sensitive environment variables

Name	Link
🔨 Latest commit	57d50a8
🔍 Latest deploy log	https://app.netlify.com/projects/docusaurus-2/deploys/6a6a83b85c9daf000877d454
😎 Deploy Preview	https://deploy-preview-12327--docusaurus-2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[SyMind]

This is a bug on the Rspack binding side. I’ll follow up on it.

[slorber]

Thanks for the analysis and the fix

Apparently it's already released in https://github.com/web-infra-dev/rspack/releases/tag/v2.1.8

@SimonSiefke could you please try upgrade and confirm if it fixes the leak?
I'm not sure what kind of tooling you use to produce these screenshots so how can I test this PR of if the new release works? Please give me a test plan I can run myself

[SimonSiefke]

Hi @slorber ,
I can confirm the leak is fixed in latest rspack!

Here some more details about the vscode-memory-leak-finder project, which I'm using for testing and generating the charts:

VS Code Memory Leak Finder Setup

Ensure using NodeJs v24.19.0 and run

git clone git@github.com:SimonSiefke/vscode-memory-leak-finder.git &&
cd vscode-memory-leak-finder &&
npm ci &&
node packages/cli/bin/test.js --only ^base.ts

Docusaurus test script

node packages/cli/bin/test.js \
  --cwd packages/e2e \
  --check-leaks \
  --measure-after \
  --measure named-function-count3 \
  --only docusaurus-i18n-build \
  --runs 4 \
  --run-skipped-tests-anyway \
  --run-network-tests-anyway \
  --inspect-process docusaurus

Result JSON will be in .vscode-memory-leak-finder-results/process/docusaurus/named-function-count3/docusaurus-i18n-build.json

Generate Charts

npm run build-charts

Charts will be in .vscode-charts

Additional Details

• The test script runs docusaurus build, and takes a heapsnapshot before and after.
• Then it parses the heapsnapshots.
• namedFunctionCount3 measures which function counts have increased between the two heapsnapshots
• For example when running build 37 times, and the number of resolveMarkdownLink functions also increases 37 times, that is very suspicious and is likely a leak
• Passing the result JSON data to an AI, it can often figure out a fix for the memory leak somehow. Not always perfectly but usually pretty good

[slorber]

I see, thanks for the explanation!

It seems very similar to this technique I've stumble upon recently: https://denodell.com/blog/your-spa-is-leaking-memory-soak-test-it

I can also confirm it works better now: #10944 (comment)

Please let us know if you find other memory leaks