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.
I opened an issue about ECONNRESET error triggered by Rspack on Windows on server filles changes. It includes a repo to reproduce it. I tried most of what I could detect in this thread about such errors, but it seems tied to the Windows environment.
I had only reported one Windows issue related to how I handle POSIX as part of Rspack processing, reproduced in Meteor Blaze projects.
I’m not sure if it’s related to this one. For me all my tests of basic and examples apps has run without issues. I’ll try it on my Windows machine and get back to you on the issue with feedback.
Thank you for looking into it. I have opened a similar POSIX style issue for JorgenVatle/meteor-vite last December, the only other option I know to compile Svelte code in Meteor 3.x. The library doesn’t seem maintained.
Right now, I’m somewhat stuck between two less than optimal solutions for my active projects.
I have finally gotten past these issues and now about 75% of my tests are passing.
I am getting a few weird issues that I have no idea how to isolate/debug
I am getting a lot of “WebSocket connection to ‘ws://localhost:3005/sockjs/631/0oe411by/websocket’ failed: Invalid frame header”
Some point after that I get
methods_replication.js:112 Uncaught (in promise) TypeError: Cannot convert undefined or null to object
at Object.keys ()
at Object.update (methods_replication.js:112:31)
at store. [as update] (livedata_connection.js:326:38)
at livedata_connection.js:1211:41
at Array.forEach ()
at livedata_connection.js:1211:20
at Array.forEach ()
at Connection._performWritesClient (livedata_connection.js:1208:31)
at Connection. (livedata_connection.js:1234:14)
at Generator.next ()
I haven’t seen these in normal dev mode of our server, but it is consistently failing a few tests. What appears to happen is either some code fails to load, or some published data is failing to load (both happen in different tests). @nachocodoner do you have any suggestions on things I could isolate to figure out what is going on? Our client is fairly complex and I haven’t been able to repro it on a smaller example.
Are you using DISABLE_SOCKJS=1 in your test environment?
What exact Meteor version/branch are you on? (meteor --version or the release file)
You mentioned it only happens in test mode, are you running meteor test or meteor test-packages? With --driver-package?
How many tests run concurrently? The Invalid frame header pattern is often triggered by connection pressure, multiple clients connecting/disconnecting rapidly, which is typical in test suites but not in normal dev
Things you can try to isolate:
Set DDP_DEFAULT_CONNECTION_URL explicitly to make sure client and server agree on the endpoint
If you’re behind any proxy (nginx, etc.) in your test setup, try without it
Try adding a small delay between test groups to see if it’s a concurrency/timing issue
I only have one happen concurrently, and this is happening with a single test that I picked out using .only
The delays aren’t relevant here.
I’ll look into DDP_DEFAULT_CONNECTION_URL as a secondary option.
I had my AI dig into it and it came out with setting RSPACK_NATIVE=1
It doesn’t feel like that should be the solution, but it did resolve it across the board. I am concerned that that is hiding some deeper issue here as I don’t quite understand what that env variable means.
I dug into this and I believe I found the root cause
The HMR proxy is active in test mode but shouldn’t be
In packages/rspack/rspack_server.js, the dev HMR proxy is enabled when Meteor.isDevelopment && !process.env.RSPACK_NATIVE. The problem is that meteor test --full-app sets Meteor.isDevelopment = true, so the proxy starts up but in test mode, there’s no rspack dev server listening (test mode uses rspack build, not rspack serve)
This means http-proxy-middleware with ws: true registers itself as a WebSocket upgrade handler on the HTTP server, pointing to a port where nothing is listening.
This interferes with SockJS WebSocket connections, producing the Invalid frame header errors. The broken connections cause reconnects, which then trigger the TypeError: Cannot convert undefined or null to object crash in methods_replication.js (a changed message arrives with undefined fields during the reconnection flow).
Why RSPACK_NATIVE=1 fixes it: it disables the HMR proxy entirely (!process.env.RSPACK_NATIVE becomes false), so no more WebSocket interference
The fix is straightforward (I think) skip the proxy in test mode:
In the meantime, RSPACK_NATIVE=1 is a valid workaround tbh it’s not hiding a deeper issue, it’s directly addressing the cause by disabling a proxy that has no business running in test mode
I’ll open a PR for this but @nachocodoner can you confirm to me for which branch I need to open a PR ? It’s the release-3.4.1 right ? Or on devel directly ?
That is likely the issue. I had to apply the same change for native and introduced the fix in 3.4.1, so the tests should likely benefit from it as well.
@dupontbertrand: you can provide the fix based on release-3.4.1. If it is confirmed soon, I will include it. Let me know if you can take care of it, otherwise I can handle it. I’m about to release the RC, so I’m watching last-minute reported issues that are easy to handle so they can be covered.
