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

At most, add a flag in the core to opt in to that CopyRspackPlugin config so you can enable it in your image,

As noted above, Meteor 3.4-beta.13 will add a new override file: rspack.config.override.<extension>, where <extension> matches your project’s rspack.config.<extension>.

If this file exists, its overrides and extensions apply to all configs, similar to the project root. This makes it easy for environments to provide their own aside the app’s config. For example, you can add the override below to your container image to apply custom rules to all apps using it.

const { defineConfig } = require("@meteorjs/rspack");
const rspack = require("@rspack/core");

module.exports = defineConfig((Meteor) => {
  return {
    plugins: [
      new rspack.CopyRspackPlugin({
        patterns: [
          {
            from: "public",
            to: ".",
            noErrorOnMissing: true,
          },
        ],
      }),
    ],
  };
});

This still seems a workaround for your issue, but hopefully at some point in the future we can understand the root issue, maybe others will hit it soon in other circumstances we can hunt down over time. At least with this solution we don’t need to add CopyRspackPlugin for everyone or pay the performance cost of extra config.

I’ll update here when it’s ready to test for everyone. The implementation and tests are already in place.


Btw, if the issue with assets only happens as part of build, you don’t need to include CopyRspackPlugin in development mode. You can add it only when Meteor.isBuild is true, and save the overconfig. So you could do something like this:

plugins: [
  Meteor.isBuild && new rspack.CopyRspackPlugin({
    patterns: [
      {
        from: "public",
        to: ".",
        noErrorOnMissing: true,
      },
    ],
  }),
].filter(Boolean),

For 3.4-beta.13 I have one issue affecting the local package case reported by @storyteller. If a quick fix isn’t possible (for the moment no luck on fixing it), I’ll postpone it or provide a workaround, since it’s an edge case.

3 Likes

I’m using this version now and it is working fine.

Last extensibility & contributions release available: 3.4-beta.14. This release marks the final beta, wrapping up long-awaited production bundle optimizations, the last round of feedback for the Rspack integration, and including the remaining community contributions.

We’ve also included the final round of community contributions:

With this final beta, we’ve reached the key milestone pursued throughout the Meteor–Rspack integration. The next step is the official 3.4 release.

In about a week, we’ll publish the release candidate, the last chance to apply quick or critical fixes. After a short testing period, we’ll proceed with the 3.4 final release. During this time, we’ll continue reviewing feedback, updating docs and tutorials for Rspack, and preparing for the official launch.


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

:page_with_curl: Modern Build Stack docs

:comet: Meteor Bundler optimizations docs

:zap: Rspack Bundler integration docs

5 Likes

After many hours and 3 or 4 different attempts, I am glad to say that I moved one of my projects to 3.4.
What I learned:

  • did a lot of mistakes in how I built some of the parts of my project in React.
  • in VS Code I was using a dead end launch configuration. It worked for exactly what I was doing, but it did not with any other things.
  • Rspack is fast.
  • besides Eslint, Rspack keeps a lot of things in check as far as the project structure goes.
  • defining global variables is really elegant. I used them mostly for things such as url roots for CDNs or other services.

The main issue I encountered in VS Code was that everything worked ok if I started the script from package.json and not much worked when starting with the Run and Debug of VS Code. This, combined with cumbersome innovation sneezed out of my brain years back in the shape of local NPM packages.

From here, looking forward to more improvements based on the documentation available.

Thanks a lot guys and I apoligize @nachocodoner if you ever felt your work was not appreciated. It was, been around long enough to understand what it takes to make something like this happen. Thank you.

4 Likes

Don’t need to apologize for anything. I appreciate you shared feedback constructively based on the issues you faced. I understand it can be hard to move to new configurations and tools. One good thing in Meteor 3.4 is that you can opt in and switch when you feel it’s the right moment. While you do, it’s great to get feedback from a developer’s perspective, above all in a beta.

I’m glad that thanks to the feedback, the release now has better docs, helpers and options for the common setups, and most importantly, the channel stays open to keep improving. Above all, I wanted everyone to feel the initial goals of this long-needed effort, which I started years ago in private and later with some public experiments, and see not only faster build times, but also smaller bundles and modern setups available for everyone who needs them via an integration to the Meteor core.

Let’s keep improving it through feedback and get it in an even better state in time!

8 Likes

This is probably not related, but I’m kinda stumped.

Has there been any big difference in how Meteor handles npm in the last couple updates? Our circleci is failing to install oxlint and tsgo correctly and its blocking me from testing this on our ci.

if (!nativeBinding) throw loadErrors.length > 0 ? Error("Cannot find native binding. npm has a bug related to optional dependencies (https://github.com/npm/cli/issues/4828). Please try `npm i` again after removing both package-lock.json and node_modules directory.", { cause: loadErrors.reduce((err, cur) => (cur.cause = err, cur)) }) : Error("Failed to load native binding");

I also got rspack to fail ot install


Error: Cannot find native binding. npm has a bug related to optional dependencies (https://github.com/npm/cli/issues/4828). Please try `npm i` again after removing both package-lock.json and node_modules directory.

Cannot find module './rspack.linux-x64-gnu.node'
Require stack:
- /home/circleci/app/node_modules/@rspack/binding/binding.js
Cannot find module '@rspack/binding-linux-x64-gnu'

I’ve had essentially the same CI config for multiple years and have never had anything similar to these problems, but updating to beta.14 and I can’t seem to get around it.

I had something similar; adding the following to my Dockerfile “fixed” it:

RUN rm -rf package-lock.json

It goes right before the meteor npm

RUN rm -rf package-lock.json
RUN meteor npm --no-audit --no-fund install  && meteor build --platforms web.browser --directory ../app-build

Probably not ideal to remove the package-lock.json, but that’s what’s working for me for now.

Meteor Client Bundles 3.3 vs 3.4 in my main project:

Meteor 3.3:
js: compressed 706kb, total size: 2.472kb

Meteor 3.4:
js: compressed 529kb, total size: 1.658kb

2 Likes

@nachocodoner I just updated from beta.12 to beta.14 and my build is now failing with this error:

p5s4j 11/18 4:05:28.176 PM e[35mThe following entries will be added to .gitignore:e[0m
p5s4j 11/18 4:05:28.176 PM e[35m  • _builde[0m
p5s4j 11/18 4:05:28.176 PM e[35m  • */build-assetse[0m
p5s4j 11/18 4:05:28.176 PM e[35m  • */build-chunkse[0m
p5s4j 11/18 4:05:28.176 PM e[35m  • .rsdoctore[0m
p5s4j 11/18 4:05:28.176 PM e[32m✅ Gitignore entries for Meteor Modern-Tools build context directories addede[0m
p5s4j 11/18 4:05:28.182 PM e[91me[31mRspack plugin error: Could not find rspack.config.js, rspack.config.ts, rspack.config.mjs, or rspack.config.cjs. Make sure @meteorjs/rspack is installed correctly.e[0m
p5s4j 11/18 4:05:28.195 PM e[0me[91mpackages/core-runtime.js:189
p5s4j 11/18 4:05:28.195 PM             throw error;
p5s4j 11/18 4:05:28.195 PM             ^
p5s4j 11/18 4:05:28.195 PM 
p5s4j 11/18 4:05:28.195 PM Error: Could not find rspack.config.js, rspack.config.ts, rspack.config.mjs, or rspack.config.cjs. Make sure @meteorjs/rspack is installed correctly.
p5s4j 11/18 4:05:28.196 PM     at getConfigFilePath (packages/rspack/lib/processes.js:167:9)
p5s4j 11/18 4:05:28.196 PM     at runRspackBuild (packages/rspack/lib/processes.js:434:22)
p5s4j 11/18 4:05:28.196 PM     at module.wrapAsync.self (packages/rspack/rspack_plugin.js:305:9)
p5s4j 11/18 4:05:28.196 PM     at processTicksAndRejections (node:internal/process/task_queues:105:5)
p5s4j 11/18 4:05:28.196 PM 
p5s4j 11/18 4:05:28.196 PM Node.js v22.21.1
p5s4j 11/18 4:05:29.210 PM The command 'bash -l -c meteor npm i --no-audit  && meteor build --directory ../app-build' returned a non-zero code: 1
p5s4j 11/18 4:05:29.220 PM e[0m"error":"Error on build job.",

I don’t have any other changes besides Meteor bump.

Have you tried running npm install again from the project/app? I’ll update that message to suggest it, since this already came up before and required doing that.

1 Like

I think this is a Node/npm ecosystem issue (see #4828), triggered more visibly after upgrading to Rspack 1.6.0 (which adds new native bindings) and Node 22.21.0.

It’s a known npm bug with optionalDependencies where a stale or platform-mismatched package-lock.json can cause npm to skip installing the correct native binding. When that happens, npm looks at the lockfile, decides “no native optional dependency for this platform”, and the install fails, the same error a lot of other projects are seeing if you look into the log message.

1 Like

I haven’t changed our Dockerfile.

So I believe we already do what you’re asking me to do, see:

FROM zcloudws/meteor-build:3.4-beta.14 as builder

WORKDIR /build/source
USER root

RUN chown zcloud:zcloud -R /build

USER zcloud
COPY --chown=zcloud:zcloud . /build/source

RUN meteor npm i --no-audit  && meteor build --directory ../app-build

FROM zcloudws/meteor-node-mongodb-runtime:3.4-beta.14-with-tools

COPY --from=builder /build/app-build/bundle /home/zcloud/app

RUN cd /home/zcloud/app/programs/server && npm i --no-audit

WORKDIR /home/zcloud/app

ENTRYPOINT ["/scripts/startup.sh"]

And again, something definitely changed from .12 to .14. It was working fine and is still working fine with .12.

So great! I bet your build times have also improved.

Ok, the Client bundle shaved off 20%. Anyone noticed a doubling of the server memory?

254MB with 3.3.2 and 515 with 3.4-Beta.14

Yes, the same from 3.3.2 to 3.4-Beta-8.

I’m working on the last reports: legacy build issues and problems updating rspack and @meteorjs/rspack when upgrading from beta versions, since I now have reproductions for these.

Regarding the server RAM doubling issue, I haven’t noticed anything, and it’s true I haven’t really checked it deeply yet. It’s a good reminder to look at those metrics as well. I’ll review RAM usage in some apps migrated to Rspack. Have you seen this effect in simple Meteor apps too? I’ll test those as well, because if it doesn’t happen generally it may be related to specific apps, dependencies, or config that I’d like to understand.

Any extra info or reproductions you have are welcome, so I can focus on all reports and review them straight away.

2 Likes

2 posts were split to a new topic: Meteor + RSPack + React Router in framework mode is it possible?

I was able to research the issue. With your image I was able to see it happening consistently and reproduce it with this one-line command:

meteor create --release 3.4-beta.12 --react 34beta14 && \
cd 34beta14 && \
meteor build --directory ../test-app && \
meteor update --release 3.4-beta.14 && \
meteor build --directory ../test-app

This has appeared in previous betas, and the workaround has been to re-run npm install after the NPM dependency bump (rspack dependencies in the case of beta.14 when meteor run/build). I tried to find a way so that meteor build / meteor run would ensure the new node_modules are installed correctly, but I couldn’t get it to work. It seems that if you run npm install or bump dependencies inside the Meteor process (a Node process), the node_modules are not guaranteed to be installed properly in the running project. In this case, @meteorjs/rspack and rspack bumped in beta.14 end up missing from node_modules (and actually more dependencies are missing), and you need to run npm install from your shell instead. I tried several approaches, including doing it outside the project context, but none of them fixed this automatically.

Because of that, I updated meteor update to bump rspack and @meteorjs/rspack earlier during the Meteor release update, and added a log message suggesting to run npm install to keep dependencies and the project stable.

In any case, I suggest adding an automatic retry after the first meteor build attempt as a likely fallback fix:

RUN meteor npm i --no-audit \
  && (meteor build --directory ../app-build \
      || (meteor npm i --no-audit && meteor build --directory ../app-build))

With this, it worked in my environment. I hope this helps.

3 Likes

I’ve been able to test the Galaxy app (a real-world production app) migrated to Meteor 3.4-beta.14 with Rspack and check the RAM consumption. On my side, I haven’t seen any increase in RAM usage, actually, I’m seeing lower RAM usage on the live data graphs.

I’m not completely sure what’s happening in your cases, but it’s likely that your issue is coming from somewhere else. If Rspack is the culprit, it might be related to a specific dependency or configuration, and I’d really like to have a reproducible setup to investigate.

@paulishca, @harry73: could I ask for your help to create a minimal app that demonstrates the issue? Ideally, we’d have the exact code isolated so we can compare how Meteor 3.3.x and 3.4 behave in terms of resource usage for your specific use cases.

Since I’ve seen several apps that don’t show this RAM usage problem, I’m planning to move forward with the RC soon. At this point, I don’t see this as a general issue affecting the major of apps.

If there are other users who have already migrated to Rspack, could you also check and share your server RAM usage results?

1 Like