New 3.4-beta.12 Release, Faster Builds, Smaller Bundles and Modern Setups with the Rspack integration ⚡

announce releases
81

Yeah, I noticed Meteor 3.4 doesn’t jive well with any fancy caching stuff now so I disabled it too

1 Like
82

It does look like it might be a slightly more generic issue than just meteor.

I’m sure we could do something to mitigate, but seems like it should be coordinated with the RSPack team

83

Yes, it could be an Rspack issue. It’s marked experimental, so it may still need improvements.

I haven’t hit it myself. It might be due to the project sizes I’ve used for the integration. I’m now working on larger apps and still haven’t seen it. Do you have any means to reproduce it?

Would enabling the in-memory cache help? Use:

cache: true,
experiments: { cache: true }

You won’t see gains on a full app restart, but it should help incremental rebuilds in dev. This can show if the problem is with serialization/deserialization of Rspack’s persistent cache used by default in Meteor.

If you can confirm the in-memory cache behaves better, I’ll enable it by default for all apps. Otherwise, I’ll disable caching entirely so projects don’t run into these issues until it’s fixed by Rspack. I still encourage everyone to find reproducible cases so Rspack can get more data to resolve it.

Anyway, with and without cache, Rspack is faster than pure Meteor bundling of your app code. But hopefully they can make it stable.

84

For me, registration and login work correctly. I tried several times. Could you check after meteor reset` just in case (I don’t think is related).

image
image1200×318 15.9 KB

I’m not sure what the issue is, it might not be related to your Rspack integration. Please provide exact steps to reproduce.

2 Likes
85

@nachocodoner You’re right, it’s fine. There was a repeatable error on my dev system, and after reading your post here, I tracked it down. Yet again my local mongdb for the project had been corrupted. This is the second time this has happened in the past few months. I believe it has something to do with how I’m maintaining two separate folders for the project (one with tested working code, and one with new code) as I update different node packages, etc. Each has its own separate copy of the mongodb, so I’m not quite sure how it’s happening. I tried to avoid the things that I thought may have been responsible last time.

This time I just verified that everything was good in the older folder, and finder-coped my-project/.meteor/local/db/ from the older folder to the newer folder. I ran a meteor reset, re-built, and all was well. :slight_smile:

1 Like
86

@nachocodoner would it be helpful to open a forum thread where people can contribute their rspack.config.js setups, or is that better handled as a github issue? I can start a thread here if that would be helpful.

87

Is there a way to separate out server and client unit tests?

This is something that was nice about meteor’s old test infrastructure but doesn’t work with RS pack

This is also part of what makes using the test entry point harder since there isn’t really a way to specify the 3 different possible entries (.app-test., server .test. , and client .test.)

Also on my large app even after the ignore fix I am getting memory errors pretty frequently

<--- JS stacktrace --->

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

 1: 0x10473625c node::OOMErrorHandler(char const*, v8::OOMDetails const&) [/Users/zacholigschlaeger/.meteor/packages/meteor-tool/.3.4.0-beta.11.1byw6heih2ak++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
 2: 0x10490c4fc v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/Users/zacholigschlaeger/.meteor/packages/meteor-tool/.3.4.0-beta.11.1byw6heih2ak++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
 3: 0x104b1bc24 v8::internal::Heap::stack() [/Users/zacholigschlaeger/.meteor/packages/meteor-tool/.3.4.0-beta.11.1byw6heih2ak++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
 4: 0x104b19fc4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/zacholigschlaeger/.meteor/packages/meteor-tool/.3.4.0-beta.11.1byw6heih2ak++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
 5: 0x104b0e5ac v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/zacholigschlaeger/.meteor/packages/meteor-tool/.3.4.0-beta.11.1byw6heih2ak++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
 6: 0x104b0ede4 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/zacholigschlaeger/.meteor/packages/meteor-tool/.3.4.0-beta.11.1byw6heih2ak++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
 7: 0x104af2104 v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/Users/zacholigschlaeger/.meteor/packages/meteor-tool/.3.4.0-beta.11.1byw6heih2ak++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
 8: 0x104f0dbb4 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/Users/zacholigschlaeger/.meteor/packages/meteor-tool/.3.4.0-beta.11.1byw6heih2ak++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]
 9: 0x1053d1af4 Builtins_CEntry_Return1_ArgvOnStack_NoBuiltinExit [/Users/zacholigschlaeger/.meteor/packages/meteor-tool/.3.4.0-beta.11.1byw6heih2ak++os.osx.arm64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.arm64/dev_bundle/bin/node]

I have not been able to break it down and figure out exactly what causes it, but its not happening every time
Doing this does resolve it, but thats a pretty high amount of memory
NODE_OPTIONS=“–max-old-space-size=40960”

Edit:
Figured out the memory problem was at least partially because unit tests were including the .spec. files which is not what they used to do, which was causing it to include my app test, which then includes way too much and causes it to crash

In my repo

npm run test
and
npm run test-app

both fail when by old Meteor infrastructure they would pass.

88

It seems that has been fixed:

I’ll check in which Rspack version it’s released, likely 1.6.0. There’s also a chance that a beta will include it for early testing.

Remember that your Meteor app can now use any specific Rspack version you define in your package.json. To use the latest version, just update it there. As long as it’s newer than the one bundled by the Meteor Rspack package, it will be preserved. Later, when an official Meteor Rspack update includes a newer version, it will become the new default automatically. But you can always adopt the latest Rspack version whenever you prefer.

89

New extensibility & contributions release available: 3.4-beta.12. This release ensures further Rspack support for real-world app projects, enabling new features and fixes. It also marks the start of contributions from the Meteor community.

Since the last report, I’ve been able to integrate Rspack into real-world apps like Galaxy and successfully get it running and felt all speed gains and modern build environment. I also reviewed additional feedback provided during your transitions.

  • Added Meteor.compileWithRspack, a quick helper for rspack.config.js to define npm dependencies that should be treated as modern or require transpilation through Rspack’s SWC. Useful for npm packages written in modern-only syntax.
  • Added Meteor.compileWithMeteor, a quick helper for rspack.config.js to define npm dependencies that should be skipped by Rspack and handled directly by Meteor’s bundler and Node runtime. Needed for native dependencies.
  • Added Meteor.setCache([true|false|'memory']) as a shortcut to configure Rspack cache in rspack.config.js.
  • Added support for Rspack code-splitting using splitChunks.
  • Improved dev environments where ROOT_URL points to an external server instead of localhost.
  • Ensured shared code can properly resolve modules, allowing node/server-specific modules to be processed as no-ops in client code, supporting natural code sharing.
  • Ensured cache refreshes properly when configuration files like rspack.config.js, .swcrc, .babelrc, or tsconfig.json change, keeping the persistent cache in sync.
  • Ensured externalHelpers in .swcrc is enabled only for client code, since server code already supports needed syntax features.
  • Fixed an issue with Service Workers causing infinite reloads in dev mode.

We’ll continue addressing feedback on the Rspack integration, with the focus now on ensure stability in production environments, eager tests behaving better, support additional modern setups, and other feedback we get with it.

Besides, we’ve included several community contributions that were pending for inclusion in Meteor 3.4, among them:

We still have more contributions to include in this release, especially after Hacktoberfest, during which we received the highest number of contributions in years. Some of these remaining updates will be part of the next beta and round up the final Meteor 3.4 release.

5 Likes
91