I was thinking the same when working on the integration. Then I felt it was important to mention Rspack, because this time it is not tightly coupled to the Meteor tool. You can upgrade your own Rspack version in your Meteor app’s package.json and receive updates without waiting for Meteor.
Rspack is now integrated in a looser way. In my view, it is good to be transparent about the tools behind the scenes. Users can then evolve them independently, understand what complements the Meteor experience, and know that any future Rspack plugin or feature can benefit their Meteor app.
This message is not fully accurate. The Meteor client usually involves more than 99ms. The 99ms refers to the Rspack HMR step that enables fast reload. The Meteor bundler still needs to link Atmosphere packages with the Rspack output. client-rspack refers to the client configuration for the app written within the rspack.config.js. All this is why the distinction matters.
If you run meteor profile, you can see the stages for each tool. In development, the client side looks simpler because Rspack HMR handles quick refresh. On the server, both bundlers act separately.
This distinction allowed us to deliver Meteor bundler optimizations in Meteor 3.3 and measure what was saved with Meteor bundler internal changes and other improvements. It also helped us understand how offloading app bundling work to Rspack brought most of the gains in Meteor 3.4.
With all this, my intention in mentioning Rspack is to help users understand the tools behind the improvements. Clear references to what each tool does make the system easier to grasp and extend. It is also fair to acknowledge the Rspack OSS community whose work helps us move faster. For accuracy on the process, I would keep mentioning the tool behind the scenes that makes the gains possible.
I understand that for marketing or Meteor identity purposes, we may want to present everything as part of Meteor and its benefits. But as technical users, we should also allow ourselves to know more about the tools behind it.
What others think about this?
PD: This is something we can update later, and even move the rspack config to meteor.config.js. But the above is my take on preserving the specific mention of each tool.
) - no feedback and no upgrade)… I don’t want to specifically maintain it, but since it is the core functionality for my app(s) and I 100% invest into Meteor+Vue in the future anyway (from what I see - this is the most efficient toolset on the market with the most logical, leanest structure), and there seem to be not many people figured out the true elegance of Meteor+Vue, I could just publish it as a fork or a “spiritual successor”, while keeping the API.
Let’s make it 3.1!
