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

announce releases
206

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 [...]
1 Like
207

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

208

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?

209

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.

210

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'
}
2 Likes
211

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.

212

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:

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. :grin:

213

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.

214

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

215

I late read it but this news is sooo :heart_eyes:

2 Likes
216

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.

2 Likes
217

this worked. Thank you!

2 Likes