@jorgenvatle should be able to answer.
New stability release available: 3.4-beta.8. This includes fixes on Windows and improvements in the integration.
With this, and unless a critical issue appears in the Meteor-Rspack flow, I consider the first phase of the official 3.4 release complete. This phase focused on stability and was key to deliver the work done over the last months around Meteor-Rspack integration. We now have a working published version supporting all Meteor skeletons and allowing migration of existing projects. Meteor apps can now run with Rspack in dev mode, bundle visualizer mode, Cordova mode, build mode, testing with all options, and deploy to production. Detailed docs are also available to explain the approach and guide the migration process. A new modern test suite also ensures configs remain compatible and regressions are avoided in future updates.
The second phase will focus on extensibility. While stability is ready for you to start migrating your apps, we know projects may need special configs or customizations. This phase is about your feedback. As you adapt your apps, share your needs. We’ll suggest configs, packages, alternatives, or considerations to cover edge cases. This will help us expand the integration and improve the docs.
This phase is also about experimenting with new setups and customizations. We’ll provide ways to customize the new build contexts (_build, build-chunks, etc). I’d also like to experiment with Angular support in Meteor, since Rspack already supports Angular with its own config approach similarly as ours with Meteor. The idea is to complement Meteor’s config with it. Other customizations will be added as we understand needs and explore new ideas.
A call to action for every Meteor developer who believes in a new era of tools and a modern dev experience. The way we deliver ideas and products with Meteor is shifting, and your support is key. Every bit of feedback helps shape and expand this work. Please take a moment to contribute and support these improvements.
5 Likes
Amazing! Very excited for the future of Meteor
1 Like
I get
import { defineConfig } from '@meteorjs/rspack';
^^^^^^
SyntaxError: Cannot use import statement outside a module
when I try to run it. Is type:“module” needed in the package.json? Just asking, because it is also not set when I create a new app with the template.
The main problem I am still having is changing the rspack config file doesn’t seem to always invalidate the cache. So I have to remove _build a lot when trying to debug rspack issue. It really slows down my ability to figure out my issues.
You don’t need to use "type": "module" in package.json. If you remove it, does it work? If for some reason you need it, I’d appreciate a minimal repository that reflects your setup, and why you need it. That way I can test it directly and explore possible extensions.
By default, the cache is enabled to improve development speed on rebuilds. If you ever need to disable it, you can override your rspack.config.js to prevent any cache from being used. You can also force files to be regenerated on every build. For example:
export default defineConfig(Meteor => {
return {
output: {
clean: true // deletes old files in _build before emitting
},
cache: false, // disable cache
experiments: {
cache: false // disable persistent cache (experimental flag)
}
};
});
With this config, cache is completely disabled and files re-emitted. Test if this improves the experience.
To ensure strict cleaning, it now happens as part of meteor reset, this should be enough for all sorts of cache cleaning. Alternatively, you can use plugins to wipe the build directory, node_modules/.cache, .meteor/local, for instance, clean-webpack-plugin . Or you can simply run rm -rf _build (or rimraf _build using npm package) before your meteor run process. Creating an npm script for this can make it easier to automate.
Explore what works best for you to keep rspack.config.js changes refreshing properly. We may improve cache cleaning in meteor reset if needed, or allow automatic cache disabling through an env variable, making it easier for those who do frequent config changes.
About rspack.config.js file, Rspack does not auto-reload when you edit rspack.config.js, similarly as webpack’s behavior, so we can’t get sort out the need to restart the app manually.
1 Like
Thanks for the info!
I was able to finally get my app to launch.
Random things that tripped me up that may help other people.
I have a package “@react-native-async-storage/async-storage” that is ill-formed so I had to do an alias that directly mapped to a file
"@react-native-async-storage/async-storage": [
path.resolve(__dirname, "./node_modules/@react-native-async-storage/async-storage/lib/module/AsyncStorage"),
],
One of my packages uses a .node binary so I had to add this rule:
module: {
rules: [
{
test: /\.node$/,
type: "asset/resource",
},
The thing that tripped me up is there is a webpack package node-loader that is deprecated. That does not work with meteor so you have to use the asset/resource
I had an ill behaving package that had jsx in js file and had to add this:
{
test: /\.js$/, // Target .js files
use: {
loader: "builtin:swc-loader",
options: {
jsc: {
parser: {
syntax: "ecmascript",
jsx: true, // Enable JSX parsing for JavaScript files
},
},
},
},
},
My layout.html was not next to my client entry file, so it was not automatically loaded. I had to move my layout.html to the correct folder and then it worked fine.
I haven’t tested the testing infrastructure or really any usage of this, but the speed improvements are pretty big and I’m excited for this to be stabilized.
3 Likes
I tried running unit tests and it looks like this is loading too many files.
I have folders that the tool should ignore that its including, causing rspack to completely crash.
I think the eager-tests.js needs to respect the .meteorignore file for my project to work.
Yeah, we usually do not use that parameter within our Meteor applications. But after uprading it to Beta 8, the app crashes with the error:
[Rspack Client Error] /var/project/rspack.config.js:1
import { defineConfig } from '@meteorjs/rspack';
^^^^^^
SyntaxError: Cannot use import statement outside a module
I guess it is because the created config files uses the import syntax.
When emptying the whole file, the app seems to build but crashes with:
ReferenceError: $RefreshSig$ is not defined
Woo! Windows is fixed! Thanks!
Deploy still not working though :(.
Preparing to upload your app...
Uploaded app bundle to upgrade todo-sample.meteorapp.com to version 3.
Galaxy is building the app into a native image.
Waiting for deployment updates from Galaxy...
Building app image...
Deploying app...
******************************************************************************
ERROR: Failed to deploy new app version: 3.
Galaxy failed to deploy your app. The final deploy status was: Deploy Failed.
Your app is currently stopped.
See https://galaxy.meteor.com/app/todo-sample.meteorapp.com/logs for details.
******************************************************************************
The galaxy logs show this:
8fg4j
2025-09-11 22:23:53-07:00Error: MONGO_URL must be set in environment
8fg4j
2025-09-11 22:23:53-07:00 at Object.<anonymous> (packages/mongo/remote_collection_driver.ts:113:11)
8fg4j
2025-09-11 22:23:53-07:00 at Object.defaultRemoteCollectionDriver (/app/bundle/programs/server/npm/node_modules/meteor/mongo/node_modules/lodash.once/index.js:71:21)
8fg4j
2025-09-11 22:23:53-07:00 at setupDriver (packages/mongo/collection/collection_utils.js:29:27)
8fg4j
2025-09-11 22:23:53-07:00 at new Collection (packages/mongo/collection/collection.js:52:18)
8fg4j
2025-09-11 22:23:53-07:00 at AccountsServer._initializeCollection (packages/accounts-base/accounts_common.js:114:20)
8fg4j
2025-09-11 22:23:53-07:00 at new AccountsCommon (packages/accounts-base/accounts_common.js:62:23)
8fg4j
2025-09-11 22:23:53-07:00 at new AccountsServer (packages/accounts-base/accounts_server.js:31:5)
8fg4j
2025-09-11 22:23:53-07:00 at module.wrapAsync.self (packages/accounts-base/server_main.js:7:12)
8fg4j
2025-09-11 22:23:53-07:00 at Module.wrapAsync (/app/bundle/programs/server/npm/node_modules/meteor/modules/node_modules/@meteorjs/reify/lib/runtime/index.js:252:8)
8fg4j
2025-09-11 22:23:53-07:00 at module (/app/bundle/programs/server/packages/accounts-base.js:33:9)
8fg4j
2025-09-11 22:23:53-07:00 at fileEvaluate (packages/modules-runtime.js:335:7)
8fg4j
2025-09-11 22:23:53-07:00 at Module.require (packages/modules-runtime.js:237:14)
8fg4j
2025-09-11 22:23:53-07:00 at Module.mod.require (/app/bundle/programs/server/npm/node_modules/meteor/modules/node_modules/@meteorjs/reify/lib/runtime/index.js:30:33)
8fg4j
2025-09-11 22:23:53-07:00 at Object.require (packages/modules-runtime.js:257:21)
8fg4j
2025-09-11 22:23:53-07:00 at evaluateNextModule (packages/core-runtime.js:167:26)
8fg4j
2025-09-11 22:23:53-07:00 at runEagerModules (packages/core-runtime.js:206:3)
8fg4j
2025-09-11 22:23:53-07:00
8fg4j
2025-09-11 22:23:53-07:00Node.js v22.18.0
Why would I need to set MONGO_URL when deploying to Galaxy?
Worked for me each time I deployed your shared project.
This is the command that I run for deploy. Maybe you need to establish to create a free mongo for your free app.
meteor deploy meteor-rspack-starter.meteorapp.com --owner <my-username> --free --mongo
Hey, great that you got it working. Depending on the project you may need extra config. Thanks for sharing your specifics.
For everyone: import aliases need to be migrated to the Rspack approach. I’ve documented this in the docs.
About loaders: a loader config lets your bundler import specific file types. For Less files use less-loader; for Markdown files use markdown-loader; many others exist. For .node binaries, this is deprecated in favor of asset/resource. asset/resource can also handle images and more as a built-in feature. Learn more in the Rspack asset modules docs.
About moving layout.html near the entry point so Meteor processes it: this is now required. Similarly for CSS files. If you must keep the original path and still have Meteor process them automatically, use the new modules fields in meteor package.json. I still recommend keeping all HTML and CSS that Meteor should process near the entry point so it can skip expensive scans elsewhere. It is preferable to let Rspack handle these, especially CSS files that can be imported in code and resolved automatically. Still, you can rely on Meteor’s eager mechanism for HTML and CSS, which is also a valid and working approach.
In the next beta phase, I will see if I can improve the eager mechanism for loading tests. I’ll also try to ensure entries in .meteorignore are discarded. Remember you can rely on testModule and provide a manual index file for all your tests. Anyway, I will optimize eager mode in the next releases.
1 Like