Hello community!
Meteor 3.4 will use a modern bundler to speed up builds and rebuilds to match common JS tools throughput, and add features long requested in Meteor: tree shaking, secure final bundles, community plugins, bundler lifecycle hooks, advanced bundle analytics, and much more.
I’ve opened this Meteor forum thread to share over time performance updates, showcase modern bundler features and benefits with this integration, and welcome your questions and feedback.
The Meteor-RSPack integration began as hobby work years ago, and is now moving to the Meteor core, highlighting its benefits and reasoning. Recently, I even got RSPack HMR working with Meteor’s dev server, fixing past limits on my approach. I covered the approach in Modernizing Meteor’s Bundler, and it’s great to see issues from that time got resolved in the current integration work.
For those asking about Vite, I tried my approach with Vite but ran into limits and extra overhead in automation, which needs a more complex configuration for core adoption. Meteor also has meteor-vite alternative for those who prefer.
To meet our goals within our capacity, we’re sticking with RSPack for now. RSPack is faster than Vite because it’s built entirely in Rust (Vite plans similar support via future Rolldown integration). It’s also compatible with the widely used Webpack ecosystem, so you can use its many plugins and tools.
Demo
I share a demo video showing how fredmaiaarantes/simpletasks is integrated with RSPack using a new rspack Meteor package that automates the process, and how fast development experience is achieved on code changes.
With Meteor 3.4, you will opt into a new rspack package in your existing app that will unlock all integration benefits, performance gains, and advanced bundler capabilities, with no additional configuration.
Performance
Here is a comparison of meteor profile runs for Meteor 3.2, 3.3, and the upcoming 3.4 on a checkout with RSPack integration using simpletasks app on my machine:
On average, build times drop by 75.4% in Meteor 3.4 using RSPack.
Build and rebuild phases are drastically faster. Client rebuilds now only run the RSPack step thanks to the new dev server and HMR, reducing refresh time on client changes by about 96%. Rebuild times, key to the development experience, have fallen sharply for both client and server.
The Meteor 3.4 profile separates the RSPack(Build App) and Meteor(Build App) phases, adding up to the total build time. The first phase uses RSPack to build your app code, and the second compiles packages and links code with Meteor. Meteor remains slower on its own work, but now only handles package compilation and linking. The Meteor 3.3 modern build stack with SWC also speeds up the Meteor(Build App) phase, so it’s still recommended to enable "modern": true in your project.
Meteor + RSPack benefits greatly by offloading app compilation to RSPack.
Further Work
I’m preparing a PR with the new rspack package for the Meteor core. I also plan to verify this integration across several Meteor setups to identify and fix any limitations.
As covered in another forum post, our goals for the Meteor bundler are clear and this approach takes a modern-first view. We already see promising results and will explore its limits and how to address them. So far, the benefits are clear, with no loss of standard JS workflows, and it opens our community to other ecosystems.
Call to Action
As with Meteor 3.3, we’ll release betas before the official launch to collect feedback and give everyone a chance to try a modern bundler. If you want to help early, please, create and share minimal apps in repositories that match your typical Meteor apps, including packages and configurations you use, especially those that directly affect the Meteor bundler. This lets us test the new modern bundler integration and ensure a smooth integration for you in the first betas.
