Weekly Update (May 28, 2025): New 3.3-rc.0 Release, Faster Builds Delivered! 🚀

nachocodoner · May 16, 2025, 9:22am

Hello everyone, it’s time for our weekly update!

We’ve got some exciting news, Meteor 3.3-rc.0 is out now!

This release marks the first major update to the Meteor bundler in years, with several improvements and optimizations. It includes the SWC transpiler and minifier to speed up development and builds.

It also includes important community contributions, especially around Meteor React packages, improving stability, performance for commonly used hooks; and support of React 19.

Tasks and fixes for Meteor 3.3-rc.0

Support SWC transpiler and minifier for faster dev and builds PR#13657, PR#13715
Switch to @parcel/watcher for improved native file watching PR#13699, PR#13707
Default to modern architecture, skip legacy processing PR#13665, PR#13698
Optimize SQLite for faster startup and better performance PR#13702
Support CPU profiling in Meteor 3 bundler PR#13650
Improve meteor profile: show rebuild steps and total, support --build PR#16 and PR#13694
Improve useFind and useSubscribe React hooks
Add replaceEmailAsync helper to Accounts PR#13677
Fix user agent detection and oplog collection filtering
Refine type definitions for Meteor methods and SSR’s ServerSink
Allow opting out of usage stats with DO_NOT_TRACK
Update Node to 22.16.0 and Express to 5.1.0

All merged PRs: GitHub PRs 3.3

React packages changelog: 4.0.0-beta.0

Your feedback is crucial in adjusting this beta before the official launch. Our core team is running tests, but community testing is key to ensuring Meteor 3.3 is stable. Let us know what you find!

Hands on

To update an existing app:

meteor update --release 3.3-rc.0

To create a new app:

meteor create --release 3.3-rc.0

Add this to your package.json to enable the new modern build stack:

"meteor": {
  "modern": true
}

This setting is on by default for new apps.

Note the new modern setting replaces modernTranspiler and modernWebArchsOnly from previous Meteor 3.3-beta.0 announcement. You can opt out each, see the docs. Modern Build Stack docs

Highlights

Modern Build Stack

Meteor 3.3 brings a new build stack: SWC for transpiling and minifying, @parcel/watcher for file watching, and smarter skips for legacy bundles.

Turn on "modern": true in your package.json and see rebuilds and builds fly.

Performance Highlights

On average, build and rebuild times are cut by about 50%, roughly a 2× speed-up, but actual gains range from around 30% (≈1.5× faster) up to 60% (nearly 3× faster) in the best scenarios.

Results are from fredmaiaarantes/simpletasks app on a specific machine. Your numbers may differ, but you can expect similar gains.

Curious about the gains? Run meteor profile to compare Meteor 3.2 vs 3.3-rc.0 on your project and share your results!

Development Breakdown

When running meteor run, timings from meteor profile with and without "modern": true.

Production Breakdown

When running meteor build, timings from meteor profile --build with and without "modern": true.

Build Stack Upgrade

Transpiler

The transpiler converts modern JS syntax in all app code to a cross-browser compatible version.

Meteor profiling showed most build time goes to Babel transpilation (meteor run/meteor build). To fix this, we added SWC (in Rust), which speeds up rebuilds in both development and production.

There are no breaking changes for most apps. If your app uses nested imports (not dynamic ones), it may fall back to Babel. The same applies if you use Babel plugins that SWC does not support yet. You can find SWC equivalents or disable SWC for those files.

We also added a doc page with tips for migrating and debugging the new setup.

Modern Transpiler: SWC docs

Minifier

The minifier reduces and obfuscates your app’s production bundle for security and efficiency.

Meteor profiling showed Terser spends a lot of time on production builds (meteor build). To fix this, we added the SWC minifier, which speeds up builds.

@italojs adapted the minifier from the zodern/minify-js-sourcemaps package, cherry-picked it, and integrated it into Meteor core, delivering the performance gains we wanted.

Modern Bundler: Minifier docs

Web archs

Web archs are the builds Meteor generates for modern browsers, legacy browsers, and Cordova.

Skipping web.browser.legacy and web.cordova speeds up builds. In development mode, Meteor skips these archs when they aren’t needed.

Thanks to @9Morello for driving this forward!

Modern Bundler: Web Arch docs

Watcher

The watcher listens for changes in your app’s code files and triggers quick recompilations.

Meteor now uses @parcel/watcher. This improves development mode speed and compatibility by using native, recursive file watching on all OS. It also fixes a long-standing Linux delay where file changes took 5 seconds to register.

Modern Dev Server: Watcher docs

Tools: CPU profiling

We added environment variables to generate and inspect CPU profiles. In his guide, @italojs shows how to run these profiles and pinpoints Babel as a bottleneck now replaced by SWC in 3.3.

We also enhanced meteor profile with a --build flag to profile the production build and highlight minifier gains. The rebuild reports now emphasize total rebuild times to help you track client and server build improvements.

React 19 Support

We updated the meteor/react-packages repo to restore tests/CI and ensure compatibility with Meteor 3. Contributors also improved the performance of useFind and useSubscribe, and added React 19 support.

Try the new beta of react-meteor-data:

meteor add react-meteor-data@4.0.0-beta.0

Thanks to @welkinwong, @Poyoman39, and @PedroMarianoAlmeida for their contributions and tests!

Be aware of a breaking change: useFind describes no deps by default #431

Huge thanks to our contributors

We’re grateful to community members for testing and feedback on Meteor 3.3: @zodern, @minhna, @paulishca, @pmogollon, @ferjep, @wreiske and @schlaegerz.

Join us and contribute! Test this beta, check out Meteor GitHub issues or start with Good first issues.

What’s Next?

Meteor 3.3 – Coming Soon
- The release is complete and live.
- We’re testing and acting on feedback.
- Once testing wraps up, we’ll publish the official 3.3 release.
Meteor 3.4 – On the Horizon
- Deeper bundler integration for new production features, broader plugin support, and faster builds by moving more bundler steps to a modern tool.

Stay tuned, and as always, happy coding!

nachocodoner · May 16, 2025, 9:23am

We’ve also added a patch for percolate:migrations (we maintain it, but it’s not in core yet):

Run async migrations in sequence (PR #90)

To pull in the latest changes:

meteor add percolate:migrations@2.0.1

We could make it part of the Meteor core later. What do you think? (Bring percolate:migrations to Meteor core packages · meteor/meteor · Discussion #13648 · GitHub).

nachocodoner · May 16, 2025, 10:37am

gr4vitywall · May 16, 2025, 12:23pm

Great work, y’all. Using SWC by default makes this one of the most significant releases in terms of DX in a long time.

storyteller · May 16, 2025, 7:51pm

I’m very much for integrating percolate:migrations. It is the de facto standard already and is necessary for any production apps.

janmp · May 19, 2025, 7:20am

with "modern": true I get this error message:

Parcel watcher error on /Users/jan-michaelpilgenroeder/Code/plAIground: [Error: Events were dropped by the FSEvents client. File system must be re-scanned.]

Seems to work fine though. Don’t notice any problems.

nachocodoner · May 19, 2025, 12:32pm

I was able to reproduce this issue on my Mac M1 reported here as well. It seems specific to Mac environments and only shows up with meteor profile. Did you see this log during a normal meteor run when working in development mode?

janmp · May 19, 2025, 1:30pm

Yes, I got it with a normal meteor run when working in dev mode (M1 as well):

“MONGO_URL=‘[…]’ meteor run --exclude-archs web.browser.legacy --settings=settingsLocal.json”

schlaegerz · May 19, 2025, 5:34pm

I also saw this, on a Mac (not M1)

paulishca · May 19, 2025, 7:31pm

Me too, on M1, also seems to work just fine.

awatson1978 · May 25, 2025, 5:57pm

@nochocodonor - This is brilliant work! Major kudos for swapping out Babel for Speedy Web Compiler! Gave it a spin this weekend, and it worked great.

Screen shot of a P2P app using Interplanetary File System (IPFS) protocol (most of you will be familiar with IPFS via Ethereum), built with Meteor and SWC.

I’ll provide one bit of feedback/feature request for consideration. When we try to integrate the Helia IPFS library, we’re getting the following error:

meteor run --port 3000 --settings config/settings.helia1.json
[[[[[ /Volumes/SonicMagic/Code/ipfs-on-fhir-prototype-rust ]]]]]

=> Started proxy.                             
=> Started HMR server.                        
=> Started MongoDB.                           
W20250525-12:53:40.924(-5)? (STDERR) [meteor-desktop] will not watch for changes is .desktop because there is no .desktop/settings.json or desktopHCP is set to false.  Remove this plugin if you do not want to use desktopHCP.
W20250525-12:53:40.929(-5)? (STDERR) ❌ Failed to load Helia modules via wrapper: Failed to load helia: No "exports" main defined in /Volumes/SonicMagic/Code/ipfs-on-fhir-prototype-rust/node_modules/helia/package.json
I20250525-12:53:40.930(-5)? Starting FHIR P2P server (Direct Helia priority)...
I20250525-12:53:40.930(-5)? 🔍 Testing IPFS connection strategies (Direct Helia priority)...
I20250525-12:53:40.930(-5)? 📦 Strategy 1: Trying direct Helia import...
I20250525-12:53:40.930(-5)? 🚀 Initializing direct Helia with config: {
I20250525-12:53:40.930(-5)?   repoPath: '/tmp/ipfs-helia-3000',
I20250525-12:53:40.930(-5)?   swarmPort: 4001,
I20250525-12:53:40.930(-5)?   wsPort: 4002,
I20250525-12:53:40.930(-5)?   enableGC: true,
I20250525-12:53:40.930(-5)?   enablePubsub: true,
I20250525-12:53:40.930(-5)?   enableRelay: true
I20250525-12:53:40.930(-5)? }
I20250525-12:53:40.930(-5)? 🚀 Starting Direct Helia IPFS node...
I20250525-12:53:40.930(-5)? 📍 Repo path: /tmp/ipfs-helia-3000
I20250525-12:53:40.930(-5)? 📍 Swarm port: 4001
I20250525-12:53:40.930(-5)? 📍 WebSocket port: 4002
I20250525-12:53:40.930(-5)? 📦 Loading Helia modules with SWC-compatible imports...
I20250525-12:53:40.930(-5)? ❌ Direct Helia failed: Failed to load Helia modules: Failed to load helia: No "exports" main defined in /Volumes/SonicMagic/Code/ipfs-on-fhir-prototype-rust/node_modules/helia/package.json
I20250525-12:53:40.930(-5)? 💡 Check: npm install helia @helia/unixfs libp2p...
I20250525-12:53:40.930(-5)? 📦 Strategy 2: Trying simple HTTP client...
W20250525-12:53:41.034(-5)? (STDERR) ❌ Failed to start embedded Helia (direct): Error: Failed to load Helia modules: Failed to load helia: No "exports" main defined in /Volumes/SonicMagic/Code/ipfs-on-fhir-prototype-rust/node_modules/helia/package.json
W20250525-12:53:41.034(-5)? (STDERR)     at HeliaEmbeddedDirect._loadModules (server/ipfs-helia-direct.js:133:13)
W20250525-12:53:41.034(-5)? (STDERR)     at processTicksAndRejections (node:internal/process/task_queues:105:5)
W20250525-12:53:41.034(-5)? (STDERR)     at HeliaEmbeddedDirect.start (server/ipfs-helia-direct.js:152:23)
W20250525-12:53:41.034(-5)? (STDERR)     at createHeliaNode (server/ipfs-helia-direct.js:416:17)
W20250525-12:53:41.034(-5)? (STDERR)     at server/main.js:92:25
W20250525-12:53:41.034(-5)? (STDERR)     at /tools/static-assets/server/boot.js:453:5
W20250525-12:53:41.034(-5)? (STDERR)     at /tools/static-assets/server/boot.js:503:5
W20250525-12:53:41.034(-5)? (STDERR)     at startServerProcess (/tools/static-assets/server/boot.js:501:3)
I20250525-12:53:41.034(-5)? Connecting to IPFS at http://localhost:5001
I20250525-12:53:41.034(-5)? ✅ Connected to IPFS node: 12D3KooWE9Q56iunu9u8k6deKSnZLnwRGAernNsY4fBMwczhHivJ
I20250525-12:53:41.034(-5)? IPFS Protocol Version: undefined
I20250525-12:53:41.034(-5)? IPFS Agent Version: kubo/0.35.0/Homebrew
I20250525-12:53:41.034(-5)? ✅ Simple HTTP client connected successfully!
I20250525-12:53:41.034(-5)? Network methods updated: Simple HTTP (Available: true)
I20250525-12:53:41.034(-5)? ✅ IPFS client initialized
I20250525-12:53:41.034(-5)? 🔧 Client Type: Simple HTTP
I20250525-12:53:41.034(-5)? 🔧 IPFS Available: true
I20250525-12:53:41.034(-5)? 🚀 Server Port: 26323
I20250525-12:53:41.034(-5)? 
I20250525-12:53:41.034(-5)? 🎉 External IPFS daemon connected!
I20250525-12:53:41.034(-5)?    ✅ Create shares with real IPFS storage
I20250525-12:53:41.034(-5)?    ✅ Pin content to your node
I20250525-12:53:41.034(-5)?    ✅ Share via IPFS URIs and gateway URLs
I20250525-12:53:41.034(-5)?    ⚠️  Requires external IPFS daemon
I20250525-12:53:41.034(-5)? 
I20250525-12:53:41.034(-5)? ✅ FHIR P2P server started

This error occurs when Node.js cannot resolve the entry point for a modern ES module package. The helia package uses the newer ES module “exports” field in its package.json to define entry points, but the Node.js module resolver is looking for the traditional “main” field instead. This typically happens when:

Module Resolution Mismatch: The package uses modern ESM “exports” syntax (e.g., "exports": { ".": "./dist/src/index.js" }) but the importing environment expects the older CommonJS “main” field (e.g., "main": "index.js").
Toolchain Compatibility: Build tools like Meteor’s SWC compiler or certain Node.js versions may not fully support the newer “exports” field resolution, causing them to fall back to looking for “main” which doesn’t exist in modern ESM-only packages.

Root Cause: Modern IPFS/libp2p ecosystem packages (helia, @helia/unixfs, libp2p, etc.) are published as ESM-only with “exports” fields, but Meteor’s current module resolution doesn’t properly handle this newer package.json format, especially when using dynamic imports in server-side code.

Impact: This prevents server-side usage of modern IPFS libraries in Meteor applications, forcing developers to either use older HTTP client approaches or implement complex bundling workarounds.

Request Before releasing official SWC support, add support for modern ESM “exports” syntax (e.g., "exports": { ".": "./dist/src/index.js" })

nachocodoner · May 28, 2025, 1:12pm

Great to see you get a sucessfully adoption of SWC in your project!

We’re aware of the ESM-only export fields limitation in Meteor. There’s a community PR to address this, but we’ll add core support as part of a modern bundler integration in future versions unless the existing PR gains more attention. We’ve already contributed to that PR and are available to assist further with direct core contributions for this complex, bundler-specific feature.

github.com/meteor/meteor

Resolve package.json exports

meteor:devel ← meteor:feature/package-json-export-field

opened 04:38AM - 18 Dec 24 UTC

zodern

+523 -50

This implements [package.json exports](https://nodejs.org/docs/latest/api/packag…es.html#package-entry-points), following [Node's specification](https://nodejs.org/api/esm.html#resolution-algorithm). It should be feature complete and spec compliant. This PR is the build-time implementation. The runtime implementation is in https://github.com/meteor/install/pull/1. In the past some bundlers had added additional features to resolving package.json exports. However, in the past couple years all of the main bundlers have removed any additional features and standardized on implementing it as in Node's specification. This implementation attempts to do the same. Meteor uses the same resolver for both commonjs and ecmascript modules, which adds some complexity when implementing the specification. I'm not aware of any remaining issues, but it is likely I missed something. Meteor's bundler resolves the original import id at both build time, and during run time. This requires the bundles to have all of the information needed to resolve the imports, including anything relevant from package.json files. Since Meteor now uses the `exports` object in package.json files, this could drastically increase the bundle size. For example, the `@babel/runtime` package has an `exports` object that is 32kb. This implementation takes care to minimize the additional size from the `exports` objects - only the specific parts of the `exports` object needed for the files imported by the app are included in the bundle, and those parts are rewritten when possible to be smaller. It also excludes any other main fields from the package.json when there is an `exports` field. This is likely a large breaking change. When the resolver finds an `exports` field, it disables any other main fields in the package.json. It also restricts what files the app or other packages can import from the package. Additional features that could be implemented in later PR's - [ ] The related feature of the [`import` field](https://nodejs.org/docs/latest/api/packages.html#subpath-imports) in package.json files. There should be very little left to do for this - [ ] Build plugins will need to be able to add additional conditions, such as the `svelte` condition for apps or packages that have a build plugin to compile svelte files - [ ] It might be interesting if app developers could add conditions - along with [self-referencing](https://nodejs.org/docs/latest/api/packages.html#self-referencing-a-package-using-its-name) imports (implemented in this PR), this could be used to create different builds of an app with different files included - [ ] We don't have all of the errors and validations that Node does and described in the specification - I'm not sure build time is the right place for them, and at runtime it might not have enough of the `exports` object to be able to do them. The implementation is half ready so we could add more of the `exports` object as needed for run-time validations. - [ ] Add the development and production conditions Remaining tasks for this PR: - [x] Merge and publish https://github.com/meteor/install/pull/1, and update this PR to use the new version - [x] Update the copy of install.js in `module-runtime-hot` - [ ] Make sure existing tests pass - [ ] Test with some real apps to check how much this affects bundle size and build performance - [ ] More testing with real apps to make sure there's no unhandled edge cases that break apps or packages - [ ] If Meteor still has its [browserstack](https://github.com/meteor/meteor/tree/master/tools/tool-testing#testing-with-phantombrowserstack) testing, it should be run before this feature is released. I was careful to ensure client code is still es5, but I might have missed something. I don't have any large Meteor 3 apps to test with, so I would appreciate help with that.

nachocodoner · May 28, 2025, 4:10pm

We’ve released Meteor 3.3-rc.0 to address feedback received so far:

Fixed an issue where TypeScript projects saw no SWC speedup in app code, even though node modules and packages were accelerated.
Resolved non-fatal watcher warnings on macOS.
Made meteor profile run reliably in various scenarios and clean up any touched project files. (meteor reset to get the new changes)
Added support for swc.config.js in the app root to enable dynamic configs (for example, multiple aliases based on an environment variable).
Enabled .swcrc configs to apply differently depending on their nested file context.

This release is now closed unless a critical issue arises. Next, we’ll publish the official 3.3 version. Later, we’ll release patch 3.3.1 with fixes and updates for the new build stack based on feedback from early adopters.

Hands on

To update an existing app:

meteor update --release 3.3-rc.0

To create a new app:

meteor create --release 3.3-rc.0

Add this to your package.json to enable the new modern build stack:

"meteor": {
  "modern": true
}

This setting is on by default for new apps.

nachocodoner · May 28, 2025, 4:15pm

awatson1978 · May 29, 2025, 4:30am

Trying a second app. Anybody run into a import.meta error in other libraries?

I’ve been trying to use the latest METEOR@3.3-rc.0 with a .swcrc file:

{
  "$schema": "https://swc.rs/schema.json",
  "jsc": {
    "parser": {
      "syntax": "ecmascript",
      "jsx": true,
      "dynamicImport": true,
      "privateMethod": true,
      "functionBind": false,
      "exportDefaultFrom": true,
      "exportNamespaceFrom": true,
      "decorators": false,
      "decoratorsBeforeExport": false,
      "topLevelAwait": true,
      "importMeta": true
    },
    "transform": {
      "react": {
        "runtime": "automatic",
        "importSource": "react",
        "pragma": "React.createElement",
        "pragmaFrag": "React.Fragment",
        "throwIfNamespace": true,
        "development": false,
        "useBuiltins": false
      },
      "optimizer": {
        "globals": {
          "vars": {
            "import.meta": "{ env: { NODE_ENV: 'development' }, url: 'file:///' }"
          }
        }
      }
    },
    "target": "es2020",
    "loose": false,
    "externalHelpers": false,
    "keepClassNames": true
  },
  "module": {
    "type": "es6",
    "strict": false,
    "strictMode": true,
    "lazy": false,
    "noInterop": false,
    "ignoreDynamic": true,
    "preserveImportMeta": true,
    "resolveFully": false
  },
  "minify": false,
  "sourceMaps": true,
  "inlineSourcesContent": true,
  "isModule": true,
  "env": {
    "targets": {
      "chrome": "90",
      "firefox": "90",
      "safari": "14",
      "edge": "90"
    }
  },
  "exclude": [],
  "include": []
}

But so far, no luck. Doing a little research:

Cornerstone3D uses modern ES module syntax including import.meta for worker registration and environment detection. Meteor’s bundling system (even with SWC) is treating these as non-module scripts during the bundling phase.

Potential Solutions for MDG to Investigate:

Module Context Preservation: Ensure that when processing node_modules with ES module syntax, the module context is preserved
import.meta Polyfill: Provide a built-in import.meta polyfill during the bundling phase
Selective Module Processing: Allow certain packages to be processed as true ES modules rather than being bundled

nachocodoner · May 29, 2025, 8:07am

Could you provide a minimal repository with the expected setup and a concrete example showing the limitation? This will make it easier for us to review new bundler features and check compatibility later for your use case.

awatson1978 · May 29, 2025, 2:48pm

Sure, why not…

Cornerstone3D is a DICOM viewer for Radiology images. It’s sort of a beast of a library that uses every optimization available to squeeze every bit of performance out of the web browser… GPU optimizations, webworkers, web assembly. It’s a piece of art. But ‘minimal’ is in the eye of the beholder in this case.

@chafey May have some insights.

wreiske · May 29, 2025, 3:32pm

Neat! Have you seen OHIF? GitHub - mieweb/OHIF-Viewers: OHIF zero-footprint DICOM viewer and oncology specific Lesion Tracker, plus shared extension packages https://docs.ohif.org/

awatson1978 · May 29, 2025, 3:43pm

I have! Chris and I go way back, and I was attending OHIF meetings for a short while.

I’ve been going through the scrapyard of projects, using LLMs to refactor them to Meteor v3, and have been wanting to get the Radiology projects upgraded. I got the older cornerstone.js library integrated into Meteor v3, but it’s deprecated and doesn’t have the GPU rendering, webworkers, WASM files, etc.

If OHIF library integration works in the Meteor ecosystem, I would content myself with it. But I’m pretty sure Chris migrated to webpack for the OHIF viewer because of the Meteor bundler issues. I’d like to get Cornerstone3D back into the Meteor ecosystem, so we can integrate a quality image viewer with all the other EHR/PHR modules we have on hand.

paulishca · May 29, 2025, 3:54pm

@awatson1978 I think it should be easy to convert a ESM package into a CommonJS package and use it published or as a local NPM in your Meteor Project.