Now I’m aware of memory crashes in both dev and testing mode. This seems to happen on specific projects. At least in dev mode, none of the apps I work on have hit RAM crashes so far. It’s expected for RAM usage to rise on large projects, which is likely your case. For the testing infrastructure, the issue is more related to how many Rspack instances are loaded, and we’ve already identified that as something Meteor could improve.
This doesn’t mean there aren’t already workarounds, or things we can work on going forward. There are two areas we should track for optimizations.
First, Rspack itself has reported memory leaks and known areas to improve, for example:
- Dev server memory leaks. Users report large memory leaks when using
rsbuild dev, eventually exhausting memory and forcing them to quit apps to recover resources.
[Bug]: Memory Leak in Dev Server Causing System to Run Out of Application Memory · Issue #8976 · web-infra-dev/rspack · GitHub - Persistent cache memory usage. With persistent cache enabled (
experiments: { cache: { type: 'persistent' } }), memory usage can increase a lot depending on cache size.
[Bug]: Memory usage increases significantly when persistent cache is enabled · Issue #11185 · web-infra-dev/rspack · GitHub
For the second one, Meteor-Rspack enables persistent cache by default. One direct workaround is to disable it. There’s already a helper for that for your rspack.config.js: ...Meteor.isCache(false). Does the problem still happen if you disable the cache?
The good news is Rspack is aiming to reduce memory usage in the next Rspack 2.0. The roadmap calls out “More stable persistent cache” and “Core architecture optimization,” which should help with RAM problems.
Second, Meteor can also be part of the performance issues. One thing I’m looking into is that TOOL_NODE_FLAGS="--max-old-space-size=8192" (or even 16384) may not apply to the spawned Rspack child process. TOOL_NODE_FLAGS is mainly for the Meteor tool’s own Node.js process at startup. Rspack may not inherit it, so it’s worth trying the standard Node option instead, for example: NODE_OPTIONS="--max-old-space-size=16384". That at least raises the heap limit for Rspack and may reduce how often the crash triggers, maybe with higher values not even crashing ever (same solution Meteor has had on the past with TOOL_NODE_FLAGS).
For the Meteor 3.4.x series, I plan to dig further into Meteor-side opportunities. If NODE_OPTIONS helps, one option is to automatically inherit from TOOL_NODE_FLAGS. There may also be issues in how intermediate files are handled on the Meteor side. Either way, I’ll need help validating approaches and, if possible, getting reproductions. These problems are hard to fix without a repo that reliably triggers them, but I’ll also try to build a busy example app that hits memory limits. Your help validating these will be also really helpful.
In short, try the workarounds above and see if the errors stop. Either way, we’re aware of these memory issues. Whether through Rspack fixes (with reports and reproductions provided to them) or Meteor core changes, we’ll work toward improving this.