I also noticed it sometimes hits an EADDRINUSE error. This happens in Meteor (without rspack) too, and actually happened to me when using other tools out there. Sometimes when you kill the process in the OS, the port isn’t released properly, and you need to kill it explicitly later to restart. I’ll see if I can reproduce it consistently and fix it.
Regarding the Node version, Rspack should run using the Node and npx context from Meteor’s built-in Node. To verify this, enable verbose mode in package.json with modern.verbose=true. You should see two logs at the beginning:
If you see the full path under .meteor, then rspack is using that Node for execution.
That said, I’ve seen Rspack spawn other Node processes, and those may use the global Node version from your environment. That’s likely why you still see something like Node.js v24.11.1.
I recommend using a Node manager like Volta (or similar) so your project uses a version matching Meteor’s built-in one (meteor node --version). That keeps things consistent. Alternatively, you can adjust your PATH for your project to prioritize Meteor’s built-in Node:
Just make sure <meteor-version> and the arch match your setup.
Even if you align Node via a manager or PATH, I don’t think it explains the issue you mentioned. I see it too. Using a another Node for Rspack is fine as long as Rspack supports it, but I still recommend keeping them aligned with Meteor.
I can confirm that disabling experiments.cache in rspack.config.ts fixed that issue. It crashed just once in last few hours, compared to a crash every few minutes before with cache enabled…
Cool. Then it seems it will be very beneficial for large projects to keep it disabled. A proper fix will likely be on the Rspack side, with the persistent cache optimizations coming next.
Did using NODE_OPTIONS="--max-old-space-size=16384" help (adjust the size as needed)? That should affect the heap limit of the Rspack process directly, I think.
I was curious, with this new setup is there an easy way to build a third bundle target outside of Client and Meteor?
Our use case is we build a webworker that we put into the public folder and then reference that via a manifest file. In Meteor 3.3 we do this manually with webpack in a sub directory, but since we are integrating rspack, it would be great if we can get this working. In basic rspack it looks like the solution is usually return an array of configs, but that doesn’t seem to work with the meteor setup as is.
Right now the only thing that comes to mind is managing a separate rspack.config.js, similar to how you handled it with Webpack, running rspack separately.
I know, as you mentioned, that Rspack supports a multi-compiler option, so multiple configs in the same file can build within the same process. I haven’t tried it myself yet. As part of expanding Rspack support, it’s definitely something we can look at enabling in the Meteor-Rspack integration. That said, I think it would complicate things and affect the dynamic config nature of Meteor-Rspack. Using separate definitions looks like a simpler approach at first glance.
If you can open a GitHub issue with the suggestion, that would help. Ideally include a small “pure Rspack” example of what you want Meteor-Rspack to support, with a minimal multi-config setup and a WebWorker use case.
For some reason everything works great in development, but as soon as I build the app, i’m getting this error when running the production bundle:
packages/core-runtime.js:189
throw error;
^
Error: Cannot find package "tools-core". Try "meteor add tools-core".
at makeInstallerOptions.fallback (packages/modules-runtime.js:704:13)
at Module.require (packages/modules-runtime.js:243:14)
at Module.mod.require (/opt/bluehive-provider-master/bundle/programs/
at require (packages/modules-runtime.js:257:21)
at module.wrapAsync.self (packages/rspack/rspack_server.js:32:29)
at Module.wrapAsync (/opt/bluehive-provider-master/bundle/programs/server/
at module (/opt/bluehive-provider-master/bundle/programs/server/packages/
at fileEvaluate (packages/modules-runtime.js:335:7)
at Module.require (packages/modules-runtime.js:237:14)
at Module.mod.require (/opt/bluehive-provider-master/bundle/programs/
at Object.require (packages/modules-runtime.js:257:21)
at evaluateNextModule (packages/core-runtime.js:167:26)
at runEagerModules (packages/core-runtime.js:206:3)
at processNext (packages/core-runtime.js:128:3)
at packages/core-runtime.js:138:5
at evaluateNextModule (packages/core-runtime.js:163:14)
at evaluateNextModule (packages/core-runtime.js:202:7)
at runEagerModules (packages/core-runtime.js:206:3)
at processNext (packages/core-runtime.js:128:3)
at packages/core-runtime.js:138:5
at evaluateNextModule (packages/core-runtime.js:163:14)
at evaluateNextModule (packages/core-runtime.js:202:7)
Node.js v22.14.0
I’m completely stuck running a built copy, but development works fine. I also tried down grounding to rc.2 and still seeing the same issues. It’s odd though, because it’s only happening in this one project. I have another project that is building fine.
Edit 2: This is driving me crazy. I’ve wasted probably 10 hours trying to get this working. I’ve isolated it to my qa web server. If I run the same exact build locally on my mac, the server starts up. As soon as I rsync it over to the qa server and run it, I get the tools-core error. It’s driving me up the wall!
Edit 3:
Figured it out.
By removing the entire if (Meteor.isDevelopment) { block inside /opt/bluehive-employer-master/bundle/programs/server/packages/rspack.js the server starts. I was trying to think WHY would it think we are in development?
Well, on the QA server we had this set: NODE_ENV=development
And thus it broke our workflow. Maybe can handle that import a little more gracefully?
Now I can sleep.
Here’s my github action workflow if anyone else is having this issue:
# Patch rspack.js to remove development-only code that crashes in production
# The Meteor.isDevelopment block requires packages (http-proxy-middleware, tools-core)
# that aren't included in production builds, causing startup failures
- name: Patch rspack.js for production
run: |
RSPACK_FILE=~/removed-${{ github.sha }}/bundle/programs/server/packages/rspack.js
if [ -f "$RSPACK_FILE" ]; then
echo "Patching rspack.js to remove development-only code..."
# Replace the entire if (Meteor.isDevelopment) block with a no-op
# The block starts with "if (Meteor.isDevelopment) {" and ends with the closing brace
sed -i 's/if (Meteor\.isDevelopment) {/if (false \&\& Meteor.isDevelopment) {/' "$RSPACK_FILE"
echo "rspack.js patched successfully"
else
echo "Warning: rspack.js not found at $RSPACK_FILE"
fi
So if I understood this properly, the whole issue comes from the Meteor.isDevelopment block being executed. That block in the rspack package should not run in a production environment. The server and code inside that block is only meant to be useful in development mode, when running the app via meteor run (also without the --production flag). That code sets up the Rspack HMR server for the Meteor context, and it’s only useful for development.
Both tools-core and http-proxy-middleware npm dependencies are also treated as dev-only / dev dependencies for optimizations, so they don’t occupy more than necessary in the final build.
It seems to me that by setting NODE_ENV=development in your prod/QA environment, Meteor treats it as a development environment, and since it’s still a production build, it ends up breaking.
I will likely need to improve the condition around the current if (Meteor.isDevelopment) { block, so it only runs when the process is actually in a meteor run context, and never affects a built app running directly on Node (even with NODE_ENV=development). I’ll measure the options for this.
Sorry for the inconvenience, and thanks a lot for taking the time to catch this edge case. It helps us improve it.
I want to highlight the use of NODE_OPTIONS="--max-old-space-size=16384" (use whatever value you prefer) to make sure the increased memory heap actually applies to the Rspack subprocess used by the Meteor integration. This has helped with memory-related issues, especially during testing on an issue reported.
I suggest everyone at least try this together with the other workarounds mentioned in the original answer. Disabling persistent cache also helped in some cases. Try different combinations and see if this helps. There are also upcoming Rspack 2.0 optimizations in this area that should bring improvements in the near future.
