Build performance has always been one of Rspack’s core priorities. Compared with Rspack 1.7, Rspack 2.0 improves overall performance by around 10% , and by as much as 100% compared with 1.0.
2 Likes
I want to remind everybody that you can upgrade to any new Rspack version in your package.json on your own. You don’t need to wait for Meteor. Meteor just established a minimum compatible version.
However, we already know that in this case, the Rspack major version introduces breaking changes that could directly affect the Meteor-specific NPM package, @meteorjs/rspack, requiring a proper migration. This Meteor Rspack NPM package provides the default config needed for Meteor to work smoothly. The good news is that it can be overridden by user config, with your own rspack.config.js in your project. However, I am not sure if all migration points can be addressed this way. Anyone could try it, tell us what they find, and share it here.
In the official migration process, I will ensure we apply enhancements that also make the NPM package easier to override if any edge case is missing. We are going to make @meteorjs/rspack compatible with Rspack 2.0.0 in the next work: Support Rspack 2.0.0 by nachocodoner · Pull Request #14360 · meteor/meteor · GitHub. This will let us ensure all E2E tests for Rspack apps work as expected after the Rspack 2.0.0 changes, and let everyone get these changes without worrying about migrations. We will announce it when it is ready.
Regarding Rspack 2.0.0, I am particularly interested in whether all their work on Rspack has made the persistent cache more stable and less RAM-consuming. We have improved this as much as possible on our side in Meteor 3.4.1, but they seem to have addressed improvements in this area according to the changelogs for this new version. All other benefits are a win to keep making the dev experience faster and the bundler thinner, with tree shaking and code splitting improvements. Built-in import.defer support is really interesting since it is the successor of Meteor’s nested imports, but standardized. Built-in React Server Components would also be interesting to experiment with and see how Meteor can benefit from it.
8 Likes
@a4xrbj1 and @sanki92 have been working on their local projects to use Rspack 2.0, and have validated the fixes needed to run properly with 2.0.
This is one of the main issues you will hit during this transition.
To sum things up for anyone wanting to try the migration, I put together some steps based on what I did on a small skeleton app to make it work:
Upgrade Meteor to Rspack 2.0
1. Install packages
meteor npm install -D --legacy-peer-deps \
@rspack/core@2.0.1 \
@rspack/cli@2.0.1 \
@rspack/dev-server@2.0.1 \
@swc/core
--legacy-peer-deps is needed because @meteorjs/rspack still pins Rspack 1.x peers. @swc/core is required because 2.0 no longer installs it transitively.
2. Fix externals
Rspack 2.0 changed the default externalsType, which breaks scoped or Meteor-style names. Set it explicitly in the rspack.config.js file of your local project:
module.exports = defineConfig((Meteor) => ({
externalsType: 'commonjs',
}));
3. Fix CSS
experiments.css was removed. experiments: { css: true } was part of @meteorjs/rspack defaults. Now you need to opt in per rule in the rspack.config.js file of your local project , otherwise .css files are parsed as JS:
module: {
rules: [
{ test: /\.css$/, type: 'css/auto' },
],
},
Use css/auto if you have both regular CSS and .module.css.
Expect rough edges
@meteorjs/rspack last version (1.x.x / 2.x.x) predates Rspack 2.0. Other issues will likely follow the same pattern, defaults in 1.x that 2.0 removed. (Upgrading from v1 to v2 - Rspack)
Please try them out in your project and provide feedback here or in the GitHub issues section so we can track them all.
There may only be a few issues, like the one posted above and described in the Rspack 2.0 changelog. But just in case, we can move this verification work forward together.
We will address this in a future Meteor core release (Support Rspack 2.0 by nachocodoner · Pull Request #14360 · meteor/meteor · GitHub), once we verify all examples and E2E tests still behave correctly and allow time for broader testing. In the meantime, it’s great that this can already move forward at the project level and that people are sharing solutions.
The recommendations worked fine for me. I think CSS inside NPM is not covered. I see it is parsed as Javascript.
ERROR in ./node_modules/react-ios-pwa-prompt/dist/assets/StepList.css
× Module parse failed:
╰─▶ × JavaScript parse error: Expression expected
╭────
1 │ ._list_13twy_1{list-style-type:none;list-style:inside decimal;margin:0;padding:20px 30px}
· ─
╰────
help:
You may need an appropriate loader to handle this file type.
Later edit: It also doesn’t work for imported .css files inside React components.
{
test: /\.css$/,
type: 'css/auto',
include: [/node_modules/, path.resolve(__dirname)],
}
Does it add it like this help?
I also checked there are some breaking changes around persistent cache that don’t work properly, since the experimental config (experimental.cache) was removed and now we should use directly cache config name. I am fixing these and a few others in the PR: Support Rspack 2.0 by nachocodoner · Pull Request #14360 · meteor/meteor · GitHub
I will update later on how you can fix those locally as well. Even without persistent cache, the project works. It will be slower, but it works. I will share other workarounds later.
React Compiler as part of the Rspack SWC pipeline! This is a great improvement for React users, along with other performance and feature enhancements in the announcement notes.
For those wondering, we will move to Rspack 2.x, including the latest 2.1, in Meteor 3.6. All E2E tests already pass in our Meteor core PR. You can likely adopt it in your project, but it may require config overrides and workarounds, which you can guess them in the next Meteor PR and Rspack migration docs.
At this point, since the leap from Rspack 1 to 2 introduces many breaking changes, I recommend waiting until we hit the first Meteor 3.6 beta, which will come soon after the Meteor 3.5.x series. This version should let you upgrade your project and get Rspack 2.x support automatically, without having to touch anything.
We’ll also include Meteor-Rspack integration memory fixes on large projects, among other improvements on the bundler after all feedback we are getting from you.
Don’t hesitate on sharing your feedback, we really care on improve the build options for your Meteor apps, and with your help, we are improving from the initial efforts on modern build stack.
3 Likes