Repository example:
For a long time, the Meteor community has discussed pnpm support and the limitations of the legacy Meteor bundler around symlinks, workspace layouts, and dependency resolution. With Meteor 3.4+ and the move into the modern build stack through Rspack integration, many of these limitations are no longer blockers.
Why? Because application module resolution is now delegated to a modern bundler ecosystem through Rspack, while Meteor focuses on its own runtime specifics like Atmosphere packages. This allows Meteor applications to adopt modern package manager strategies such as:
- pnpm workspaces
- monorepos
- shared local packages
- symlink-based dependency layouts
To validate this properly, I first added E2E coverage in Meteor core:
And then created a public example repository for everybody to try:
One important detail at the moment is that when using pnpm, Meteor automatic npm installation should be disabled:
{
"meteor": {
"autoInstallDeps": false
}
}
This is necessary because pnpm itself owns dependency installation and workspace linking. Otherwise Meteor’s current Rspack auto-install management may interfere with the workspace behavior.
Besides that, the setup is essentially the same as any standard Meteor + Rspack application.
Rspack integration docs:
I still want to improve autoInstallDeps behavior for pnpm workspace scenarios in future Meteor versions. We could also officially expose a pnpm skeleton through meteor create , add it as a --example , and document pnpm workflows more directly.
But sincerely, this is no longer a blocker to start using pnpm properly with Meteor projects today.
Anybody using Meteor 3.4+ with Rspack integration should now be able to adopt pnpm-based workflows without needing custom hacks around the old bundler limitations.
This is just another example of what the modern build stack migration unlocked for the Meteor ecosystem.