Meteor 3.4 without Rspack

bricous · February 13, 2026, 7:41pm

Hello,

I’m attempting to upgrade from 3.3.2 to 3.4. I’m encountering some difficulties with older Meteor packages when using Rspack, which I’m working to resolve with Claude (for example, patched bootstrap 3, patched znewsham:dynamic-table).

While working on these issues, I noticed that if I don’t run meteor add rspack, I can still compile successfully using the SWC compiler and linker without Rspack.

Is it possible to operate this way transitionally in production in order to benefit from the latest Node version and framework fixes?

Thank you for your response.

Best regards,
Bruno

nachocodoner · February 14, 2026, 7:48am

Definitely. You can update to 3.4, and also upcoming versions like 3.4.1 or 3.5 (and so on), without opting into Rspack at all, and keep using the Meteor bundler, with or without SWC.

This has been the idea from the beginning: let Meteor users benefit from improvements and fixes in each release, while always giving them a path to migrate to modern tools when they decide it is time.

maddam · February 18, 2026, 5:40pm

How can we disable/opt out from rspack in Meteor 3.4?
Is there a guide we can follow?
I tried by just removing the rspack package (and all the build folders) but that leaves our application in a broken state, unable to resolve installed node modules at startup, so something more is definitely required to have Meteor go back to the old bundler.

As an example, at startup we’re seeing “Unable to resolve some module” errors related to packages with subpath exports; an example: js-tiktoken:

  "exports": {
    ".": {
      "types": "./dist/index.d.ts",
      "require": "./dist/index.cjs",
      "default": "./dist/index.js"
    },
    "./lite": {
      "types": "./dist/lite.d.ts",
      "require": "./dist/lite.cjs",
      "default": "./dist/lite.js"
    },
    ...etc...

It looks like packages like this one are not resolvable anymore in Meteor 3.4 if we opt out of rspack…

The major issue we’re having with Rspack is that any change in the server side code results in the browser erroring out:

This makes local development a real pain, hence the idea to go back to the old bundler… but it doesn’t seem to be that easy…

nachocodoner · February 19, 2026, 5:45pm

It’s hard to go back to the Meteor bundler in Meteor 3.4 if you rely on bundler features that aren’t enabled there.

It looks like you have a dependency that uses the ‘exports’ field in package.json. That isn’t supported by the legacy Meteor bundler. The Meteor-Rspack integration is the way to modernize and support that for Meteor apps, along with many other bundler features.

If you start using Rspack and later opt out, keep in mind those bundler features will be disabled or may stop working on the legacy bundler.

The alternative is to add each missing feature to the legacy bundler, which is intensive work and not something we have capacity, not either our direction. We did have a PR open for a long time to address this exact limitation (support ‘exports’ field):

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.

That PR hasn’t progressed enough to be included. And with less time than that PR is open, we have unlocked all modern bundler features possibilities with the Rspack integration. Meteor core direction is toward modern tools and delegation. The Rspack integration unlocks modern bundler benefits, not only features but also build speed.

If your app works with Rspack, what makes you want to opt out? Any feedback you can share to improve Meteor-Rspack integration?

maddam · February 19, 2026, 5:49pm

Thanks @nachocodoner for your input, it’s really appreciated.
We found a way to make this work. As always happens, the issue was mainly on our side, since we have a monorepo on which we launch 3 separate instances of Meteor servers (sharing the same codebase); that was, as expected, not playing well with Rspack and its cache folder.
We have it working now and it seems working well, so fingers crossed we won’t see more issues!

nachocodoner · February 19, 2026, 5:53pm

Oh, good to know another use case for running several instances of a Meteor app from the same codebase.

We got this report recently as well. Is that same use case than you? Thanks for any further details.

I’ve already taken notes and plan to include a fix for running multiple Meteor apps from the same folder in the Meteor 3.4.1 patch.

maddam · February 19, 2026, 6:07pm

Eheh, actually it’s the same project, that was our Head of Engineering posting there