3.4-rc.3 Release Candidate, Faster Builds, Smaller Bundles and Modern Setups with the Rspack integration ⚡

nachocodoner · January 9, 2026, 2:55pm

Release candidate available: 3.4-rc.3. This release ensures the official 3.4 provides a solid experience after recent important and urgent requests. Some non-critical changes were also included, as they are low risk.

Support Rspack 1.7.x series by disabling lazyCompilation, which is enabled by default in the new minor but not yet supported in the Meteor-Rspack integration.
Support the meteor update --npm option to ensure Dockerized environments can pre-bump NPM Rspack dependencies.
Support public folder asset resolution within styling files (SCSS, CSS, etc).
Do not strictly force publicPath to be overridden. You can now replace the default config in your Rspack config, allowing proper CDN URLs per environment.
Improve warning messages when entry points are missing in package.json.
Revamp the React skeleton with better defaults, router config, and visuals.
Update Node to 22.21.1 (security patch)

We are also releasing a new react-meteor-data@4.0.1-rc.1 with optimizations in hooks and comparison logic. Check it out and let us know if everything works well in your React apps.

The official Meteor 3.4 release is scheduled for January 30 as part of the Galaxy Expansion. Before then, we will ship more RCs to address any critical issues. No new features or other changes are planned for 3.4.

We are already working on 3.4.1, which will expand the Rspack integration and include more contributions. A beta of this first patch will be available shortly after that date.

Remember to check out the docs for details of the new modern build stack.

Modern Build Stack docs

Meteor Bundler optimizations docs

Rspack Bundler integration docs

mikaknu · January 10, 2026, 3:38pm

Anyone using meteor 3.4 rspack with a monorepo setup, like turborepo?

wreiske · January 11, 2026, 6:28am

Using rc.3 in production and it’s going great.

I’ve had an ongoing issue however for all 3.4 releases where my HMR seems to eventually just crash the server. e.g. if I make enough edits, the server will die:

                                              
   Building for web.browser                  |
<--- Last few GCs --->

[5423:0x72480c000]   484502 ms: Mark-Compact 4061.4 (4142.4) -> 4057.2 (4142.2) MB, pooled: 0 MB, 1163.71 / 0.00 ms  (average mu = 0.312, current mu = 0.096) allocation failure; scavenge might not succeed
[5423:0x72480c000]   486123 ms: Mark-Compact 4077.4 (4146.6) -> 4069.9 (4168.9) MB, pooled: 8 MB, 1609.75 / 0.00 ms  (average mu = 0.131, current mu = 0.007) allocation failure; scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 0x1002a6eac node::OOMErrorHandler(char const*, v8::OOMDetails const&) [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
 2: 0x10048330c v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
 3: 0x100692a28 v8::internal::Heap::stack() [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
 4: 0x100690dc8 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
 5: 0x1006853bc v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
 6: 0x100685bf4 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
 7: 0x100668f14 v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
 8: 0x100a849d8 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
 9: 0x100f45af4 Builtins_CEntry_Return1_ArgvOnStack_NoBuiltinExit [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
10: 0x10c0fa324 
11: 0x10b8f7ddc 
12: 0x23f9ccc2ca4 
13: 0x23f9ccc8e70 
14: 0x100f3b8d4 Builtins_JSToWasmWrapperAsm [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
15: 0x101003078 Builtins_JSToWasmWrapper [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
16: 0x10b9b6138 
17: 0x10b9b63d8 
18: 0x10b9b6898 
19: 0x10b9b7048 
20: 0x100eb0ef0 Builtins_InterpreterEntryTrampoline [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
21: 0x100eed290 Builtins_AsyncFunctionAwaitResolveClosure [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
22: 0x100fb84d8 Builtins_PromiseFulfillReactionJob [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
23: 0x100edd594 Builtins_RunMicrotasks [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
24: 0x100eaeaf4 Builtins_JSRunMicrotasksEntry [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
25: 0x1005ea8f0 v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
26: 0x1005eb198 v8::internal::(anonymous namespace)::InvokeWithTryCatch(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
27: 0x1005eb2d0 v8::internal::Execution::TryRunMicrotasks(v8::internal::Isolate*, v8::internal::MicrotaskQueue*) [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
28: 0x1006184f4 v8::internal::MicrotaskQueue::RunMicrotasks(v8::internal::Isolate*) [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
29: 0x100618c78 v8::internal::MicrotaskQueue::PerformCheckpoint(v8::Isolate*) [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
30: 0x1001a59dc node::InternalCallbackScope::Close() [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
31: 0x1001a5ce0 node::InternalMakeCallback(node::Environment*, v8::Local<v8::Object>, v8::Local<v8::Object>, v8::Local<v8::Function>, int, v8::Local<v8::Value>*, node::async_context, v8::Local<v8::Value>) [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
32: 0x1001a5ff0 node::InternalMakeCallback(v8::Isolate*, v8::Local<v8::Object>, v8::Local<v8::Function>, int, v8::Local<v8::Value>*, node::async_context, v8::Local<v8::Value>) [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
33: 0x1002331c0 node::Environment::CheckImmediate(uv_check_s*) [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
34: 0x100e95bac uv__run_check [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
35: 0x100e8ebcc uv_run [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
36: 0x1001a6518 node::SpinEventLoopInternal(node::Environment*) [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
37: 0x1002f14b0 node::NodeMainInstance::Run() [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
38: 0x100261d40 node::Start(int, char**) [/Users/wreiske/.meteor/packages/meteor-tool/.3.4.0-rc.3.1eh15wn5hxl++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
39: 0x19aee1d54 start [/usr/lib/dyld]

This is super annoying because I have to then restart the server to get back up and running. Often times I won’t even notice it crashed until I refresh the page and realize the server is down.

spodjasek · January 11, 2026, 3:00pm

I get such errors very frequently, even when just browsing the app without any code changes:

node:events:497
      throw er; // Unhandled 'error' event
      ^

Error: read ECONNRESET
    at TCP.onStreamRead (node:internal/stream_base_commons:216:20)
    at TCP.callbackTrampoline (node:internal/async_hooks:130:17)
Emitted 'error' event on Socket instance at:
    at emitErrorNT (node:internal/streams/destroy:170:8)
    at emitErrorCloseNT (node:internal/streams/destroy:129:3)
    at processTicksAndRejections (node:internal/process/task_queues:90:21) {
  errno: -104,
  code: 'ECONNRESET',
  syscall: 'read'
}

Node.js v22.21.1

wreiske · January 12, 2026, 2:04am

Same! I’m glad you caught it, I haven’t seen that one in a few hours and it was too far up in my scrollback buffer to catch it . I get that one too!

nachocodoner · January 12, 2026, 11:00am

I’m not aware of anyone reporting Turborepo as a monorepo solution with Meteor-Rspack integration yet. It’d be great if someone with experience could try it. If there’s anything we can do to improve support in Meteor core, I’d be happy to add it.

If this sounds interesting, please try it in a simple repo you can share, and post either any issues you hit or a working example. That way I can follow up with fixes if needed. I’m not experienced with Turborepo as a monorepo approach, so any help via a shared repository will also help me get up to speed.

spodjasek · January 12, 2026, 11:03am

And did you noticed that sometimes after it crashes, it won’t properly terminate webpack-dev-server and on next start you get this:

[Rspack Client Error] .../node_modules/webpack-dev-server/lib/Server.js:2638
        throw error;
        ^

Error: listen EADDRINUSE: address already in use :::8085
    at Server.setupListenHandle [as _listen2] (node:net:1940:16)
    at listenInCluster (node:net:1997:12)
    at Server.listen (node:net:2102:7)
    at READ_WRITE (.../node_modules/webpack-dev-server/lib/Server.js:3460:23)
    at new Promise (<anonymous>)
    at RspackDevServer.start (.../node_modules/webpack-dev-server/lib/Server.js:3458:7)
    at async CAC.<anonymous> (.../node_modules/@rspack/cli/dist/index.js:998:21) {
  code: 'EADDRINUSE',
  errno: -98,
  syscall: 'listen',
  address: '::',
  port: 8085
}

Node.js v24.11.1

And I’ve just noticed that apparently dev server runs on my default Node.js (24.11.1) and Meteor is on bundled version (22.21.1)…

nachocodoner · January 12, 2026, 11:52am

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.

nachocodoner · January 12, 2026, 1:17pm

Several notes I want to mention.

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:

[i] Meteor Npm prefix: /home/mt/.meteor/packages/meteor-tool/.3.4.0-rc.2.1kw2ggr.2tll++os.linux.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.linux.x86_64/dev_bundle/bin/npm
[i] Meteor Npx prefix: /home/mt/.meteor/packages/meteor-tool/.3.4.0-rc.2.1kw2ggr.2tll++os.linux.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.linux.x86_64/dev_bundle/bin/npx

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:

PATH=/home/mt/.meteor/packages/meteor-tool/<meteor-version>/mt-os.linux.x86_64/dev_bundle/bin:$PATH

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.

spodjasek · January 12, 2026, 1:39pm

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…

I’ll try with persistent cache later.

nachocodoner · January 12, 2026, 2:00pm

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.

schlaegerz · January 13, 2026, 9:10pm

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.

nachocodoner · January 14, 2026, 12:24pm

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.

I’ll explore these ideas later.

a4xrbj1 · January 16, 2026, 1:23pm

It’s indeed good news but please consider not doing a full quote next time. Thanks

wreiske · January 17, 2026, 3:18am

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

awatson1978 · January 17, 2026, 3:47am

Ah, I thought the HMR was due to my AWS environment not having enough memory! Interesting to know that this is something happening to others…

wreiske · January 19, 2026, 8:45pm

I opened a bug report here: 3.4-rc.3 Error: Cannot find package "tools-core". Try "meteor add tools-core" · Issue #14087 · meteor/meteor · GitHub

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

nachocodoner · January 20, 2026, 11:49am

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.

nachocodoner · January 20, 2026, 11:57am

3.4-rc.3 Release Candidate, Faster Builds, Smaller Bundles and Modern Setups with the Rspack integration ⚡ - #225 by nachocodoner

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.

paulishca · January 20, 2026, 7:14pm

@wreiske 3.4 is on 22.21.1