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.