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

nachocodoner · December 15, 2025, 9:46am

Apparently this is a problem that has been reported and also spotted in Galaxy, happening mostly in automated environments, like Docker images.

As part of Docker images, we should retry automatically. The new mechanism that bumps Rspack or NPM dependencies as part of Meteor releases runs on meteor run/build/deploy, and in some environments it’s not guaranteed that node_modules is stable after the bump. In those cases you need to run npm install and then retry the original meteor run/build/deploy command.

We will fix this in the Galaxy Push to Deploy image, since we already identified a workaround, so it can reinstall and reattempt automatically. As part of manual meteor deploy it works as you stated.

Also, I’m planning a new RC including a new command meteor update --npm, so automated processes (like images) can bump NPM dependencies earlier, run npm install next, and then meteor run/build/deploy should succeed directly. For stability new images will use something like, once the next RC.

(meteor update --npm 2>/dev/null || true) && npm install && meteor deploy [...]

jkuester · December 15, 2025, 1:00pm

Has anyone experienced issues with the SWC using Blaze or require on the client?

nachocodoner · December 15, 2025, 1:36pm

Do you refer to the Rspack integration for Blaze projects in Meteor 3.4 betas or RCs, or to SWC in Meteor 3.3 with modern config?

Blaze is supported and covered by tests in Rspack, and it was also tested starting from Meteor 3.3. Do you have any reproduction steps so we can look into the issue further?

jkuester · December 15, 2025, 4:13pm

I am migrating a Blaze app to 3.0 and want to switch to biome for lint/format but it will not support non-top-level imports which I highly use in Meteor and Blaze so I was wondering how swc will behave especially in case of switching hundreds of inline imports to require. Moving them to top level is no option and neither is dynamic import.

hexsprite · December 15, 2025, 5:27pm

Would be great to have some checks for DX so that if a user hasn’t yet set a meteor.mainModule in package.json it fails with a nicer message.

Rspack plugin error: The "path" argument must be of type string. Received undefined
packages/core-runtime.js:189
            throw error;
            ^

TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received undefined
    at Object.dirname (node:path:1457:5)
    at packages/rspack/lib/config.js:157:28
    at Array.map (<anonymous>)
    at configureMeteorForRspack (packages/rspack/lib/config.js:157:5)
    at module.wrapAsync.self (packages/rspack/rspack_plugin.js:152:5) {
  code: 'ERR_INVALID_ARG_TYPE'
}

schlaegerz · December 18, 2025, 6:16pm

I am still trying to run my final validation and this repo

Still fails “npm run test-app” even though the same test runs on Meteor 3.3 just fine.

This appears to be something to do with how puppeteer is finding items on the page.

I am going to dive a bit into it today to figure out exactly why its failing, but this as is this is a pretty bad regression for us.

This branch shows it working on 3.3:

Edit:
First thing I noticed was that “this” existed in the testing call in 3.3, but not in RS pack. I added that to the test.

Also in that branch if I do test watch, if I edit a test about 10 times. I end up with a hard test crash. So the problem is definitely not having too many files. It might be architecture? I have an M1 mac, with plenty of ram

I do see this error in my browser console:

pptr:evaluateHandle;step (meteor://💻app/app/app.js:1696840:23):8 Uncaught (in promise) ReferenceError: _to_consumable_array is not defined

So its likely a swc/rspack bundling weirdness.
It might be related to the fact that puppeteer needs to inject code to the base page to add hooks it can play around with. This might have been working on earlier versions of 3.4, I’m not sure.

nachocodoner · December 19, 2025, 5:11pm

Could you add this issue and explanation in the Meteor GitHub repository, so we can track and manage it properly?

Also, there’s an interesting report that I’m not sure will solve the RAM issues you mentioned before, but it may be possible to reduce the number of processes running:

github.com/meteor/meteor

[rspack] --full-app tests should combine mainModule and testModule into single bundle

opened 10:05PM - 15 Dec 25 UTC

hexsprite

modern-build-stack

When running `meteor test --full-app` with rspack and `testModule.server` specif…ied, rspack builds **two separate server bundles**: 1. Main server bundle (from `mainModule.server`) 2. Test server bundle (from `testModule.server`) Each bundle has its own webpack runtime with separate module caches. When both execute, modules run twice, causing errors like: ``` Error: There is already a collection named "links" ``` ### Expected Behavior (matches legacy bundler) The legacy Meteor bundler creates **one bundle** where both `mainModule` and `testModule` are eager entry points **sharing the same module cache**. From `tools/isobuild/package-source.js`: - In `--full-app` mode, mainModule is NOT cleared (unlike `meteor test` without `--full-app`) - Both mainModule and testModule are marked as eager entries in the **same bundle** - Shared module cache means imports only execute once Rspack should match this: **one bundle with both entry points sharing a single webpack runtime**. ### Actual Behavior Two separate bundles with independent webpack runtimes: ``` [Rspack Build Server] compiled successfully # Bundle 1: own __webpack_require__ cache [Rspack Test Server] compiled successfully # Bundle 2: own __webpack_require__ cache ``` Both bundles execute, each with their own module cache, causing duplicate side effects. ### Version Info - **Meteor version:** 3.4-rc.1 - **OS:** macOS (also affects Linux) ### Reproduction https://github.com/hexsprite/rspack-dual-bundle-repro ```bash git clone https://github.com/hexsprite/rspack-dual-bundle-repro cd rspack-dual-bundle-repro npm install # Without rspack - WORKS (legacy bundler, single bundle) npm run test-no-rspack # With rspack - FAILS (two bundles, duplicate execution) npm run test-rspack ``` ### Suggested Fix Build one server bundle with both `mainModule.server` and `testModule.server` as entry points, sharing one webpack runtime. This matches the legacy bundler behavior where both entries coexist in the same bundle.

I’ll start working on these new reports after the holidays. They will likely land in the 3.4.x series, since the official 3.4 release should come before and will prioritize stable, low-risk changes. In any case, it’s good to have these issues documented and ready for us to tackle with renewed energy in 2026.

nachocodoner · December 19, 2025, 5:31pm

I am migrating a Blaze app to 3.0 and want to switch to biome for lint/format but it will not support non-top-level imports
so I was wondering how swc will behave especially in case of switching hundreds of inline imports to require

I believe you’re referring to nested imports (the “does not support non-top-level imports” point). A nested import and a require() are similar in when they load, but not identical in what they return or which semantics are preserved. require() follows the standard JS mechanism. A nested import uses Reify’s semantics for binding modules, etc. But both load evaluate/cache when line where placed gets run.

So, I don’t see any issue in the migration itself. I haven’t had any problems on my end with how it loads.

I recommend trying small migration steps and seeing how it goes. Share results, and any problem if you have.

schlaegerz · December 19, 2025, 6:19pm

Ok damn, these are blocking for us, but I get that it involves specific packages that not everyone uses. Hopefully they get resolved quickly

github.com/meteor/meteor

[RSPack] [TestRegression] The timing of running unit tests has changed

opened 06:18PM - 19 Dec 25 UTC

ToyboxZach

I have in my tests something that ends up looking like this: ``` const date = ne…w Date() describe("Test Date", () => { describe("is within 1 min", () => { isWithin1Min(date, new Date()) }); }); ``` This never failed on Meteor3.3 but is consistently being off by an additional minute in my large product. It appears that the time the exectution context of the tests has started has been moved up significantly. There is an easy workaround for my case, but I'm sure this will become more problematic in different cases.

github.com/meteor/meteor

[RSPack] [TestingRegression] Frequent memory crashes on test watch

opened 06:15PM - 19 Dec 25 UTC

ToyboxZach

I have a test repro here: https://github.com/ToyboxZach/MeteorTesetApp/tree/RSP…ackBugs Run: MOCHA_TIMEOUT=30000 npm run test-app If you change the tests a bunch you end up with a node memory crash, with no useful logging. This is a minimal repro, but on my bigger repro it happens a lot more frequently, and sometimes doesn't even launch the tests before it crashes. This happens whether I do eager loading, or not. More info here: https://forums.meteor.com/t/3-4-rc-1-release-candidate-faster-builds-smaller-bundles-and-modern-setups-with-the-rspack-integration/64124/211?u=schlaegerz This works fine in Meteor 3.3 as seen here https://github.com/ToyboxZach/MeteorTesetApp/tree/Meteor33

github.com/meteor/meteor

[RSPack] [TestingRegression] Puppeteer does not work

opened 06:13PM - 19 Dec 25 UTC

ToyboxZach

I have a test repro here: https://github.com/ToyboxZach/MeteorTesetApp/tree/RSP…ackBugs Run: MOCHA_TIMEOUT=30000 npm run test-app Puppeteer is no longer able to do query selectors to be able to run tests More info here: https://forums.meteor.com/t/3-4-rc-1-release-candidate-faster-builds-smaller-bundles-and-modern-setups-with-the-rspack-integration/64124/211?u=schlaegerz But it could be related to this error that I see in the browser: ``` pptr:evaluateHandle;step (meteor://💻app/app/app.js:1696840:23):8 Uncaught (in promise) ReferenceError: _to_consumable_array is not defined ``` This works fine in Meteor 3.3 as seen here https://github.com/ToyboxZach/MeteorTesetApp/tree/Meteor33

johnysmith435 · December 30, 2025, 4:36pm

nachocodoner:

Hello everyone!

I’m excited to announce that the first release candidate of the Meteor-Rspack integration is now live.

This release marks the first step toward stabilizing and consolidating a modern bundler approach with Meteor, combining the strengths of both. With it, your app can benefit from features like tree shaking, full ESM support, secure code, modern plugins, and more.

I encourage everyone to check the new docs on the modern build stack. It’s now split into two steps: first, enabling Meteor Bundler optimizations from Meteor 3.3 with SWC, and second, adding Rspack integration for extra speed and new bundler features coming in Meteor 3.4. Both are opt-in, so if you prefer the legacy Meteor bundler, you can keep that configuration.

Highlights

Faster Build times

Meteor 3.4 goes further than Meteor 3.3 and the initial SWC adoption. With Rspack now compiling your app code, you get the speed of this modern tool built in Rust. The Meteor bundler still compiles Atmosphere packages and links the final app code, but that part was already optimized in Meteor 3.3, so you get the best of both.

With meteor profile, build times drop 75.4% and are over 4x faster. Client rebuilds now only run Rspack with the new dev server and HMR, cutting refresh time by about 90% (9x faster). Rebuild times for both client and server are now much shorter, making development far quicker.

Smaller Bundle sizes

Meteor 3.4 introduces one of the most awaited features to keep app bundles small: tree shaking. With the Meteor-Rspack integration, bundle size is significantly reduced through this built-in optimization.

After deploying fredmaiaarantes/simpletasks to a private instance on Galaxy Cloud, the client bundle size dropped by about 50% compared to previous 3.3.1 release. Client bundles are now thinner, meaning less code delivered and faster initial load times for your apps. The gains vary by app and their dependencies, sometimes gain is less, sometimes much more, as some projects have reported. You can use Glaxy alternative appstore happymod ios. Try it yourself.

image1234×362 97.5 KB

Extend your app with Modern Setups

Meteor 3.4 introduces Rspack as the modern bundler for your app code. With it, you can configure any modern setup from the community.

With 3.4 we remove past limits like using ESM packages, adopting React Router v7, building Vue or Solid apps, setting up advanced aliasing, full-featured systems like i18n with lingui, integrating bundle visualizers, and using modern Rspack plugins or existing Webpack plugins. Check out Rspack docs and Webpack articles online. Anything compatible with these tools can be integrated into your app.

We encourage you to try it out and share the benefits you discover.

Hands on

To update an existing app:
meteor update --release 3.4-rc.1
To create a new app:
meteor create --release 3.4-rc.1
Add modern to your package.json to enable the Meteor Bundler optimizations:
"meteor": {
  "modern": true
}
This setting is on by default for new apps.

Check out the requirements for Meteor Bundler optimizations on existing apps.

Add rspack package to enable the Rspack Bundler integration:
meteor add rspack
This package is added by default for new apps.

Check out the requirements for Rspack Bundler integration on existing apps.

Migration

New apps will use the skeleton of existing Meteor projects, already set up with the modern build stack with Meteor bundler optimizations and Rspack integration. This provides a base for new projects, testing and understanding the setup. You can create new apps with:
meteor create --release 3.4-rc.1 --[template]
Available templates include react, solid, svelte, vue, tailwind, and others you can check with --help.

For those who want to adapt an existing app, check the docs. They explain in detail the requirements and migration steps depending on your setup and the technologies used in your app.

Keep in mind: adopting Rspack means you’ll manually migrate your Vue, Solid, Svelte CoffeeScript, Less/SCSS and Tailwind setup. Meteor’s bundler compilers won’t be used in your app code, Rspack takes over.

Note the Meteor Rspack integration is still in progress and in beta, so keep app stability in mind.

You can experiment, adapt your app, and deploy to staging. I don’t recommend production yet. If you do, keep it low risk and help us verify it… We need a full phase of testing and migrations across different app setups to ensure proper migrations. We need your help to spot any missing pieces.

Please help us with this and stay positive. We are working hard to bring a new era to Meteor, and these efforts take both determination and patience.

Feedback

Your feedback is crucial in adjusting this beta before the official launch. Community testing is key to ensuring Meteor 3.4 and the Rspack integration is stable and flexible.

You can use this thread to ask questions.

You can also check the existing Meteor-Rspack integration forum post for more details and to share your feedback. The post will also serve as a place to add insights on the integration and explain further options and ways it can be used.

I late read it but this news is sooo

nachocodoner · January 4, 2026, 9:47am

Please consider what I mentioned in this message regarding the bump to the latest released Rspack 1.7.0. In the Meteor-Rspack integration, lazyCompilation should be disabled by setting lazyCompilation: false in your rspack.config.js.

I will disable it by default in the next 3.4 release (with Rspack 1.7.0 bumped as the minimum required) and work on understanding whether it can be supported later in the 3.4.x series.

paulishca · January 7, 2026, 8:51am

this worked. Thank you!

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.