Meteor 3.6-beta.0: Rspack 2.x, pnpm monorepos, installable PWAs, and a friendlier CLI Posting checklist

announce releases
1

Meteor 3.5 brought MongoDB Change Streams, DDP session resumption, pluggable transports, and Node.js 24. The 3.5.x patches then hardened the runtime, Rspack builds, and reconnection behavior.

Meteor 3.6-beta.0 is the first beta of the next minor release, and it is a big one for the modern build stack: Rspack 2.x with automatic migration, a pnpm monorepo skeleton with workspace-aware dependency installs, an installable Blaze PWA skeleton, an interactive meteor add, and packages and projects straight from Git.

This is a beta. It is meant for testing, not production. We are using this cycle to find the edge cases Meteor should cover by default, so every report and every successful migration you share makes the official 3.6 better.

Getting Started

Create a New App


meteor create my-app --release 3.6-beta.0

Update Your App


meteor update --release 3.6-beta.0

Highlights

Rspack 2.x

Meteor 3.6 moves the modern build stack to Rspack 2.x (PR #14360).

  • The base migration is automatic. On the first meteor run after updating, Meteor bumps @rspack/core, @rspack/cli, and @rspack/dev-server to 2.2.0 and @meteorjs/rspack to 3.0.0. If your lockfile still holds Rspack 1.x peers, that single install uses npm’s legacy peer resolution so the upgrade is not rejected. Running the app was enough to migrate our own examples; a separate meteor update --npm was not needed, although it is still a good idea in some setups.

  • Meteor’s default configuration is already Rspack 2 compatible. @meteorjs/rspack@3.0.0 adopts rspack-merge, the stable persistent cache API, built-in CSS handling, externalsType: "commonjs2", and relaxed ESM export checks so SWC-stripped TypeScript type re-exports keep building.

  • Your own tooling may still need attention. If you add custom loaders, plugins, or configuration overrides in rspack.config.js, review the Rspack 1.x to 2.x migration guide and the Rspack 2.0 announcement, and check each tool’s own compatibility notes for Rspack 2.

  • React 19.2 and the React Compiler. The React skeletons move to React 19.2, React Refresh loads through its Rspack 2 entry point, and the React Compiler is supported through the built-in SWC loader.

  • Cleaner production bundles. The HMR bootstrap is now injected only for meteor run in development, so meteor build output and native bundles no longer carry HMR runtime code.

  • Better diagnostics. Dev-server proxy failures are logged with the upstream error, request, and target, and repeated failures are summarized instead of flooding the console (PR #14348).

Thank you to @nachocodoner for this hard work and @a4xrbj1, @jfurneaux, @xet7, and @evolross for the Rspack 2 reports that shaped this work, and to @Grubba27 for the review.

These changes ship through rspack@1.4.0-beta360.0 and @meteorjs/rspack@3.0.0-beta.1. We migrated the official examples to this beta as a first validation.

:link: Meteor Rspack integration guide (3.6 preview)

pnpm monorepos and workspace-aware installs

  • meteor create --pnpm my-workspace scaffolds a pnpm workspace with a Meteor + Rspack app in apps/app, reusable client, server, and shared packages under packages/, a pnpm-workspace.yaml with a pinned pnpm version, and workspace:* links between them (PR #14421). A global pnpm installation is not required; Meteor uses the version the workspace declares through Corepack when available.

  • Rspack dependency checks now detect the workspace root and the package manager, npm, Yarn, or pnpm, from your manifest and lockfiles. Installs run from the Meteor app directory so the workspace lockfile is updated, and manual instructions use the detected manager’s commands.

  • Dependencies declared with file:, link:, portal:, or workspace: protocols are validated against their installed versions instead of being treated as invalid semver ranges.

This closes a long-standing gap tracked in #10903. Thank you to @arggh for the original report and to @zodern for the review.

Installable PWA skeleton

  • meteor create --pwa my-app scaffolds a Blaze app that browsers recognize as an installable Progressive Web App: a web app manifest, icons, a dependency-free service worker, an offline fallback page, and a minimal install prompt (PR #14473).

  • In development the service worker is installable but never caches the bundle, so hot code push keeps working. In production it caches the app shell and static assets with sensible strategies, and it never intercepts DDP traffic.

Thank you to @dupontbertrand for designing and building this skeleton.

A friendlier CLI

  • Interactive meteor add and meteor remove. Run either command without arguments to search Atmosphere, multi-select packages, and confirm from the terminal. meteor add --search <query> pre-fills the search (PR #14408).

  • Packages and projects from Git. meteor add <url|user/repo> clones a package into packages/, and meteor create <url> scaffolds a project from a repository or one of its subdirectories. --from, --from-branch, --from-dir, and --to give you explicit control, and GitHub, GitLab, and Bitbucket tree URLs are understood directly (PR #14409).

Thank you to @Grubba27 and @hexsprite for the reviews.

:link: Meteor CLI reference (3.6 preview)

Build tool and package fixes

  • Transitive npm pins from a package’s npm-shrinkwrap.json are preserved when Meteor rebuilds the package without a cached node_modules/, so package installs are reproducible (PR #14418). Thank you to @perbergland for the report and reproduction.

  • meteor --get-ready batches npm installs and prefetches local package dependencies, and exact git+https://…#v<semver> Npm.depends declarations reuse the package cache (PRs #14683 and #14681). Both are adapted from work by @mvogttech.

  • The dev bundle now ships cross-env, so argon2 native rebuilds succeed inside Meteor’s isolated npm environment and meteor update no longer fails on Windows (PR #14706). Thank you to @yalshazly for the report, @sanki92 for the earlier node-gyp-build fix that set the pattern, and @mvogttech, @Jsakdev, and @ignl for the workarounds and confirmations.

  • test-in-browser supplies jQuery again, so browser package tests run against the released Blaze version (PR #14736). Thank you to @zodern for the report and reproduction.

What Else Is New in Meteor 3.6-beta.0?

Breaking Changes

  • Rspack 2.x is required. rspack@1.4.0 needs @rspack/core, @rspack/cli, and @rspack/dev-server 2.2.0 or newer and @meteorjs/rspack 3.0.0. Meteor installs them on the next run when automatic dependency installation is enabled. If you disabled it, run the meteor npm install --save-dev ... command Meteor prints; it already includes --legacy-peer-deps when your old lockfile requires it. Custom rspack.config.js overrides should follow the Rspack 1.x to 2.x migration guide.

  • Package shrinkwrap format. The per-package npm-shrinkwrap.json moves to lockfileVersion 5 and records the declared Npm.depends versions. The first build after updating reinstalls each package’s npm dependencies once. If your app commits packages/*/.npm/package/npm-shrinkwrap.json files, expect them to be rewritten, and commit the new versions.

This beta also includes more improvements and package updates. See the Meteor 3.6 changelog for the full details, or review the pull requests merged into release-3.6 for the complete implementation history.

Help Us Test This Beta

The Rspack 2 upgrade is where your feedback matters most. Please share both successful migrations and problems, ideally with:

  • your Meteor version and the output of meteor npm ls @rspack/core @meteorjs/rspack,

  • your rspack.config.js and the relevant loader or plugin versions,

  • a small reproduction when possible.

Open an issue on GitHub or reply in this thread. Edge cases that Meteor can absorb into its base configuration will land in the next betas.

If you use an AI coding assistant, the Meteor Agent Skills catalog was updated to help with 3.6 migrations:


npx skills@latest add 'meteor/agent-skills#v1.1.0-beta.0'

See the Meteor Agent Skills guide for other installation options.

Big Thanks to Our Contributors and Sponsors

Thank you to @nachocodoner, @dupontbertrand, @italojs, @mvogttech, @sanki92, @Grubba27, @hexsprite, @zodern, @StorytellerCZ, and @julio-rocketchat for authoring, contributing to, and reviewing this release.

We also thank @yalshazly, @perbergland, @a4xrbj1, @jfurneaux, @xet7, @evolross, @arggh, @Jsakdev, @ignl, and @vparpoil for reporting issues and developing reproducible test cases.

Meteor’s continued modernization also depends on sponsors who make long-term investment in the framework possible. Thank you to our current sponsors: Galaxy, Input Logic, and CodeRabbit.

If Meteor has helped you build and grow, consider supporting what comes next through the Meteor Sponsorship Program.

What’s Next for Meteor 3.6?

This first beta concentrates the bundler and CLI work. The next betas bring the rest of the 3.6 scope while we stabilize Rspack 2 with your feedback.

  • Built-in TypeScript. Native type generation for Meteor projects with Atmosphere package coverage. Planned for 3.6-beta.1.

  • Cordova iOS upgrade, MongoDB 8 in the dev bundle, and meteor shell-completion. Planned for the following beta, with MongoDB 8 still under evaluation.

  • Node.js 26. Under evaluation for the 3.6 line.

  • Meteor 3.6 stable. After the betas settle, a release candidate and the official release.

For more details on upcoming work and priorities, see the Meteor roadmap.

1 Like
2