Pnpm support in Meteor 3.4+ with Rspack

nachocodoner · May 19, 2026, 3:20pm

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:

github.com/meteor/meteor

[Rspack] pnpm support on Meteor

meteor:devel ← meteor:pnpm-support

opened 03:13PM - 19 May 26 UTC

nachocodoner

+808 -27

Context: https://github.com/meteor/meteor/issues/10903 This PR adds E2E cover…age for pnpm workspace support in Meteor applications using Rspack as the modern build stack. For a long time, pnpm support was blocked by limitations in the legacy Meteor bundler, especially around symlink handling and workspace dependency resolution. Since Meteor 3.4+, when using Rspack integration, the application module resolution is delegated to a modern bundler and package ecosystem, while Meteor focuses on its own runtime specifics like Atmosphere packages. This unlocks support for setups such as: * pnpm workspaces * shared local packages * monorepos * symlink-based dependency layouts The E2E added here validates that a Meteor + Rspack application can work correctly inside a pnpm workspace environment. One important detail is that Meteor automatic npm installation should currently be disabled in pnpm contexts: ```json { "meteor": { "autoInstallDeps": false } } ``` This is necessary because pnpm itself owns dependency installation and workspace linking, otherwise the Meteor Rspack autoinstall management will block it. As an additional showcase, I also created a public example repository: * https://github.com/nachocodoner/meteor-pnpm-skeleton --- I still plan to improve `autoInstallDeps` behavior for pnpm workspace scenarios in the future, but this is no longer a blocker for properly using pnpm with Meteor applications built on the modern stack. Everbody with Meteor 3.4 can already get the benefit from it. This PR also serves as coverage to ensure this workflow keeps working moving forward.

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.

mikaknu · May 21, 2026, 5:44pm

Did you test npm packages with transitive dependencies with your skeleton?

I think there will be issues.

Other than that, I love this direction

nachocodoner · May 27, 2026, 12:30pm

Hey, thanks for the report!

I just pushed a fix. The root cause was resolve.symlinks: false in the Rspack config of the pnpm monorepo skeleton. That setting is a small optimization that only works when your workspace packages don’t bring their own npm dependencies, which is an oversimplified setup. Removing it restores resolution for transitive dependencies that pnpm keeps inside its virtual store (node_modules/.pnpm/), which is where most real-world cases break.

Could you give it a try and let me know how it goes? Happy to look into any edge case I might have missed.

Worth noting that this is still fully compatible with current Meteor 3.4+, no new Meteor 3.x release needed.

nachocodoner · September 15, 2026, 9:39am

Pnpm support has been improved in the latest Meteor 3.6-beta.0. This beta is important for everybody interested in understanding more about how pnpm integration works in the new Meteor-Rspack era.

Pnpm is already available for Meteor 3.4+, and there is an example in the first post about how to use it.

But as part of Meteor 3.6, we have ensured there is a skeleton available directly through meteor create:

meteor create --release 3.6-beta.0 --pnpm my-workspace

Besides, the automatic NPM dependency installation system is now aware of workspaces, so the process has been optimized to be workspace-aware and work similarly to a standalone Meteor app. Always with meteor.autoInstallDeps to false at package.json to manage them yourself.

Make sure to provide your feedback on this so that we can deliver an official Meteor 3.6 release with all the edges stable.

xet7 · September 15, 2026, 10:52pm

@nachocodoner

Is it possible to have nobuild with Meteor 3 ?

So that when I start with Meteor with node main.js it would run Javascript code from current locations. And not copy all those 40k files to .build/bundle .

xet7 · September 20, 2026, 9:08am

Meteor 3 WeKan nobuild

With new loader, starts from current location of original source code, npm_modules and ~/.meteor .

git clone https://github.com/wekan/wekan

cd wekan

./build.sh

==================== WeKan ====================
1) Setup	       3) Dev server nobuild  5) Docker		     7) CLI commands	    9) Quit
2) Dev server	       4) Tests		      6) Releases	     8) Tools
Please enter your choice: 3

== Dev server nobuild ==
1) localhost:3000		       4) CURRENT-IP:3000		      7) CUSTOM PORT + SUBDOMAIN
2) localhost:3000 + trace warnings     5) CURRENT-IP:3000 + MONGO_URL 27019   8) Kill all dev servers
3) localhost:3000 + bundle visualizer  6) CUSTOM-IP:PORT		      9) Back
Please enter your choice: 1

github.com/wekan/wekan

scripts/dev-source/start.cjs

main

'use strict';

// The installed Meteor distribution supplies Node, MongoDB and package code.
// Application JavaScript is loaded by runtime.cjs from the checkout itself.
const fs = require('node:fs');
const path = require('node:path');
const os = require('node:os');
const net = require('node:net');
const {
  spawn
} = require('node:child_process');
const root = path.resolve(__dirname, '../..');
async function waitForPortRelease(port, timeout = 15000) {
  const deadline = Date.now() + timeout;
  do {
    const occupied = await new Promise(resolve => {
      const socket = net.connect({ host: '127.0.0.1', port });
      const finish = value => { socket.destroy(); resolve(value); };
      socket.once('connect', () => finish(true));
      socket.once('error', error => finish(error.code !== 'ECONNREFUSED'));

This file has been truncated. show original

# Both menus share their URL/port prompts and environment.
DEV_COMMAND=(meteor run)
if [ "$cat" = "Dev server nobuild" ]; then
    DEV_COMMAND=(node "$WEKAN_DIR/scripts/dev-source/start.cjs")
fi

github.com/wekan/wekan

build.sh

main

#!/bin/bash
if [ -n "${ZSH_VERSION:-}" ]; then exec /bin/bash "$0" "$@"; fi

echo "Recommended for development: Newest Debian or Ubuntu amd64 based distro, directly to SSD disk or dual boot, not VM. Works fast."
echo "Note1: If you use other locale than en_US.UTF-8 , you need to additionally install en_US.UTF-8"
echo "       with 'sudo dpkg-reconfigure locales' , so that MongoDB works correctly."
echo "       You can still use any other locale as your main locale."
echo "Note2: Console output is also logged to the operation-specific path printed below."
echo "Note3: All logs use .tools/log/<operation>/YYYY-MM-DD_HH-MM-SS/."
echo "       .tools/log/ inside this repository. The path is printed when a run"
echo "       starts."
echo "Note4: Two build directories, and they are not the same thing:"
echo "       .build/  - the RELEASE bundle, from 'meteor build .build --directory'."
echo "                  .build/bundle is what is deployed, tested and packaged."
echo "       _build/  - rspack's compiled output, written by ANY Meteor compile."
echo "                  Meteor reads its main modules from _build/main-prod/, so"
echo "                  it is a handoff, not a leftover: it is gitignored but must"
echo "                  NOT be added to .meteorignore (see the note in that file)."
echo "       Both are generated. Never edit them, never commit them, and skip them"
echo "       in any tool that walks the repo - _build holds a second copy of every"

This file has been truncated. show original

nachocodoner · September 21, 2026, 11:22am

Nice work, @xet7, and thanks for exploring this. Avoiding unnecessary copying and generated files is definitely worth pursuing if it makes working on WeKan faster and lighter.

It would help to explain a bit more what “no-build” actually means here: what work is avoided, what still needs compilation or preparation, and what happens at startup or after a source change. From what I understand, it avoids the conventional application bundle, but source transformation and Meteor package preparation still happen differently, mostly in memory. That distinction would help everyone understand the tradeoffs.

My main question is whether we can bring those benefits into the existing Meteor pipeline rather than maintain another execution path alongside it.

Rspack is about more than producing a bundle. It gives us a shared foundation for modern JS/TS, React Compiler, CSS tooling, assets, caching, HMR and production optimizations. A source-loaded approach can support these too, but someone still needs to integrate and maintain all that behavior. Offloading many of those responsibilities to a tool like Rspack makes a lot of sense, and is broadly how modern frameworks have evolved: the build step is one part of a larger development pipeline, not necessarily something that has to mean heavy or unnecessary work. I would prefer improving that shared tooling rather than duplicating those responsibilities.

That does not mean keeping every intermediate step we have today. We will keep improving the core integration as we get more real-world feedback and identify opportunities to simplify it, reduce unnecessary work or disk output, and make the overall pipeline lighter.

This is also why contributions from projects like WeKan would be so valuable. I would really encourage bringing reusable improvements directly as Meteor PRs. It does not need to be the whole no-build runtime at once: removing a copy step, reusing package preparation, reducing intermediate output, or improving the Rspack handoff could each be useful on their own.

It would also be useful to compare clean startup, cached startup, first usable page and edit-to-visible-result time, so we can see where the gains actually come from.

Maybe this deserves a separate forum thread too. This has grown beyond pnpm support into a broader discussion around source loading, caching, build output and simplifying Meteor’s development pipeline. It could be a good place to document the experiment, collect measurements and track possible core improvements.

For me, the goal is not to defend having a build step. It is to do only the work that is really needed while keeping Meteor maintainable and flexible.