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.
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.
@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.