./packages folder is what I use.
Hey my friend @nachocodoner.
I don’t use nested imports in this project - it’s a relatively small project and always uses the latest Meteor. I also tried to read all the docs and installed meteor add rspack.
For context: It’s a small project to binge YouTube channels https://binge.quave.dev. I’m probably the only user hehe. It’s 100% made by AI - I’m testing Cursor and Claude configurations to code in Meteor like we do at Quave. It’s already working well in many cases. We’ll open-source it once it’s done, and we already have something published in our meteor-template (Claude.md and agents), but I’m not updating there all the time since I’m working on the Binge repo.
I’m stuck on this step and I’ve tried twice:
➜ web git:(main) ✗ meteor npm start
> start
> MONGO_URL=mongodb://localhost:27017/binge-ai meteor --settings private/env/dev/settings.json
[[[[[ ~/Documents/quave/ws/binge/web ]]]]]
=> Started proxy.
=> Started HMR server.
[Rspack Server Error] Error: config file "/Users/filipe/Documents/quave/ws/binge/web/node_modules/@meteorjs/rspack/rspack.config.js" not found.
at loadRspackConfig (/Users/filipe/Documents/quave/ws/binge/node_modules/@rspack/cli/dist/index.js:658:75)
at RspackCLI.loadConfig (/Users/filipe/Documents/quave/ws/binge/node_modules/@rspack/cli/dist/index.js:796:34)
at RspackCLI.createCompiler (/Users/filipe/Documents/quave/ws/binge/node_modules/@rspack/cli/dist/index.js:680:50)
at Object.handler (/Users/filipe/Documents/quave/ws/binge/node_modules/@rspack/cli/dist/index.js:284:44)
at /Users/filipe/Documents/quave/ws/binge/node_modules/yargs/build/index.cjs:1:8993
at j (/Users/filipe/Documents/quave/ws/binge/node_modules/yargs/build/index.cjs:1:4956)
at _.handleValidationAndGetResult (/Users/filipe/Documents/quave/ws/binge/node_modules/yargs/build/index.cjs:1:8962)
at _.applyMiddlewareAndGetResult (/Users/filipe/Documents/quave/ws/binge/node_modules/yargs/build/index.cjs:1:9604)
at _.runCommand (/Users/filipe/Documents/quave/ws/binge/node_modules/yargs/build/index.cjs:1:7231)
at [runYargsParserAndExecuteCommands] (/Users/filipe/Documents/quave/ws/binge/node_modules/yargs/build/index.cjs:1:58539)
[Rspack Client Error] Error: config file "/Users/filipe/Documents/quave/ws/binge/web/node_modules/@meteorjs/rspack/rspack.config.js" not found.
at loadRspackConfig (/Users/filipe/Documents/quave/ws/binge/node_modules/@rspack/cli/dist/index.js:658:75)
at RspackCLI.loadConfig (/Users/filipe/Documents/quave/ws/binge/node_modules/@rspack/cli/dist/index.js:796:34)
at RspackCLI.createCompiler (/Users/filipe/Documents/quave/ws/binge/node_modules/@rspack/cli/dist/index.js:680:50)
at Object.handler (/Users/filipe/Documents/quave/ws/binge/node_modules/@rspack/cli/dist/index.js:415:44)
Loading plugin `rspack` from package ... -
It never ends, 20 mins running already:
Hey @filipenevola, thanks for helping test this 
About the console error: did you run npm install? Also, is @meteorjs/rspack listed in your package.json (latest is 0.0.48, but you may see another version 0.0.46 is fine)? It should install automatically once you add rspack and run your app, just checking.
The docs might be off about meteor add rspack. Can you check which rspack version was installed? It should be rspack@1.0.0-beta340.8 (you can run meteor add rspack@1.0.0-beta340.8) in case an older version with the wrong code was used.
I also assume you did meteor update --release 3.4-beta.8, the version needs to be updated to also get the core capabilities to work.
Let me know if any of that fixes it.
Everything you said I have done before sending the first message.
Except @meteorjs/rspack@0.0.48 was not in my package.json (not sure why) - it was at 0.0.46, but even after updating it and installing again, the issue persists.
Anyway, not sure what to do next. See a few screenshots:
Last try:
Before last:
Can you create a new repository with the app contents removed (blank page) but keep the file structure intact? If it’s a monorepo, leave it as is. Just enough to run an empty page and hit the issue you are getting, so we’re closer to a reproducible setup for me to find a fix for it.
Also, try: meteor create --release 3.4-beta.8 --react. Does the new app run, or do you get the same error continously?
You’re on Mac ARM, right? My initial tests showed it working there, but I’ll run some on my machine to see if I can reproduce your problem.
It’s a monorepo, but I don’t think that’s the source of the issues.
I’ve deleted everything, but it still gets stuck.
I’ll invite you to the repo 
and also send you the “cleaned up” branch in private.
Edit: sent in pvt here on Discourse.
2 Likes
Actually issue is lack of support in monorepos. When describing workspaces in package.json, all dependencies (at least devDependencies like @meteorjs/rspack) of workspace packages are installed at the workspace root if possible, to avoid duplication.
I need to support monorepos so the default rspack.config.js can resolve where @meteorjs/rspack lives (root of the monorepo).
I’ll make sure the next betas include this fix, and that your app and the ones others have sent me are all compatible with Rspack.
2 Likes
Is there anything else in your setup I should know? Have you added your local package to .meteor/packages file?
I already have an app in the modern test suite that declares two local packages: one in the packages folder and another in a custom my-packages folder via METEOR_PACKAGE_DIRS. Both load correctly in the app tests. So I’m thinking your app might define them differently.
Could you isolate the issue in a minimal repo?
I just tried to run my main app with the new bundler. Most of my Code is Coffeescript. The new bundler seems to require js for the entry points (client/main and server/main ) wich is only a minor inconvenience, so I changed that. Then it requires all imports of coffee script files to end on .coffee
That’s a problem for me because the vs code plugin, that gives me ts type checking in cs does not work if imports of coffeescipt files have the file type ending (also that’s more changes than I can do right now just for testing purposes).
@janmp: For CoffeeScript (and other projects), you need to tweak rspack.config.js to make it work (as docs state).
There’s a simple example in the modern tests for a .coffee project:
As shown there, package.json entry points can be .coffee files. You don’t need every file to end with .coffee if you set the proper resolve extensions, that will make you write your imports without the extension as it will be able to resolve .coffee files automatically if found.
In the next beta, there’s a new way to create Meteor projects with CoffeeScript enabled so that it can serve as example config for any coffescript user (meteor create --coffeescript, not yet available).
Let me know how it goes, or if you have any further question.
2 Likes
I have adjusted my repro to show the test setup bug I am having
ignore.test.ts should be ignored but is throwing an error when I run my tests
meteor test --driver-package meteortesting:mocha --port 3050
This is a problem in my main app because I have a large repo and the test is pulling in so much that I get an OOM problem.
New extensibility release available: 3.4-beta.11. This adds extended support for setups shared with us to ensure Rspack integration stays flexible.
Since the last release I’ve received reports of issues on specific projects and setups that required targeted fixes. Changes in this release include:
- Support for
rspack.config.mjsandrspack.config.cjsto enforce strict ESM or CommonJS. This avoids errors seen withrspack.config.js, which is meant to resolve both but sometimes failed. By default, new apps now use CJS syntax inrspack.config.js, matching Rspack’s default and keeping consistency across docs and examples. - Ability to customize build context folders using
buildContext,assetContext, andchunksContextin meteor config inside package.json. - Chunks and assets generated by Rspack now set cacheable headers in production, same as Meteor core assets.
.meteorignoreentries now also apply to the Rspack watcher, preventing it from watching irrelevant paths..meteorignorealso applies to test eager-loading (when notestModuleis defined in package.json), improving performance on large projects.- Two new skeletons for
meteor create:babelandcoffeescriptapps with Rspack, showing how to keep Babel or Coffeescript configured. - Monorepo support: if
rspack.config.jsfrom@meteorjs/rspackisn’t found in the current folder, it will look up parent folders. - Other improvements:
- Better cache usage on the client bundle.
- Early exit on Rspack setup errors to avoid infinite waiting.
- Fixed crashes with React server-side components.
We’ll continue to review reproductions of your setups to cover missing cases in upcoming extensibility releases. Please share them so the next release is ready and flexible for everyone. We will also start migrating apps like Galaxy to ensure the process works smoothly, so large production apps are targeted and successfully migrated.
8 Likes
I do a lot of local development but use a cloudflared tunnel to access it.
When running a different URL, like ROOT_URL=https://dev.example.com , the RSPack runs the websocket port on 8080 and no longer allows HMR.
This is a simple fix that worked for me:
devServer: {
client: {
webSocketURL: {
hostname: process.env.ROOT_URL ? new URL(process.env.ROOT_URL).hostname : 'localhost',
port: 443,
protocol: 'wss'
}
}
},
7 Likes
I’ve been having some caching issues lately where the new bundle builds but the files are cached.
ReferenceError: handleOpenURL is not defined
at ./imports/ui/landing/landing.js (https://removed/__rspack__/client-rspack.js:44646:15)
at __webpack_require__ (https://removed/__rspack__/client-rspack.js:76409:31)
at ./lib/template-helpers.js (https://removed/__rspack__/client-rspack.js:48166:83)
at __webpack_require__ (https://removed/__rspack__/client-rspack.js:76409:31)
at ./lib/helpers.js (https://removed/__rspack__/client-rspack.js:46797:73)
at __webpack_require__ (https://removed/__rspack__/client-rspack.js:76409:31)
at ./api/listen/listen.js (https://removed/__rspack__/client-rspack.js:35686:68)
at __webpack_require__ (https://removed__rspack__/client-rspack.js:76409:31)
at ./imports/ui/components/recorder/recorder.js (https://removed/__rspack__/client-rspack.js:40939:74)
at __webpack_require__ (https://removed/__rspack__/client-rspack.js:76409:31)
When I visit https://removed/__rspack__/client-rspack.js it is the old bundle, when I go to https://removed/__rspack__/client-rspack.js?v=2 it works (cache buster). Like the other meteor files that are included, can we get a hash added to these so the files in development are always the correct files referenced?
Notice each of these has a hash, but the client-rspack does not.
1 Like
Amazing effort! I’m getting the following error with beta 11:
node:internal/event_target:1101
process.nextTick(() => { throw err; });
^
Error: Cannot find module '/_build/main-dev/lib/worker.js'
at Function._resolveFilename (node:internal/modules/cjs/loader:1365:15)
at defaultResolveImpl (node:internal/modules/cjs/loader:1021:19)
at resolveForCJSWithHooks (node:internal/modules/cjs/loader:1026:22)
at Function._load (node:internal/modules/cjs/loader:1175:37)
at TracingChannel.traceSync (node:diagnostics_channel:322:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:235:24)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:171:5)
at MessagePort.<anonymous> (node:internal/main/worker_thread:226:26)
at [nodejs.internal.kHybridDispatch] (node:internal/event_target:827:20)
at MessagePort.<anonymous> (node:internal/per_context/messageport:23:28) {
code: 'MODULE_NOT_FOUND',
requireStack: []
}
1 Like
@wreiske: Do you think your cloudflared tunnel issue would improve if we auto-apply the config you shared when we detect ROOT_URL in dev is not localhost or the local ip? At a minimum, we can document this case on new docs.
On the cache issues: I recently enabled client-side caching, which may be why they’re popping up now. I plan to add more cache controls, like auto-refresh when files such as rspack.config.js or other Meteor env files change. Adding a ?hash like Meteor does is also worth trying. Cache can also disabled as mentioned here, but indeed cache availability is something I would like to improve.
@wreiske: Has your cache issues related on full restarts of your app? Or as part of HMR (refresh on changing client code) experience?
I’ll work on improving these areas for the next betas.
Is this part of an existing production-like app?
Have you isolated the problem? How are you importing worker.js? If you can share a repo that reproduces the issue, I can work on a fix for that setup.
Yes, I tried to migrate an existing production app. I do not import worker.js anywhere.
I’ll try to make a small repro app
1 Like
@nachocodoner , auto-apply the config could be good. Making it as frictionless as possible to have it work out of the box for different ROOT_URLS IMO is important. It was something that worked before, and now with RSPack it’s “broken” without doing a manual workaround.
On caching, even full restarts have issues because the cache control on my cloudflare caches at the edge if it’s asked to cache at all. I have to go bust the cloudflare cache to get the new client. I added a rule temporarily to just NOT cache anything from the __rspack__ folder, which is helping, but still would be better to include the hash= on the URL so that we can still cache the bundle, but if the bundle changes it busts the cache because the hash changes.