Meteor-RSPack Integration: A Modern Bundler Meets Meteor 3.4

[harry73]

awesome work

What does that mean for the Vue front-end? Currently, it is supported via meteor-vite. RSPack would support it. Which choice will be the official one?

Thanks.

[nachocodoner]

Adding RSPack to compile your app code lets you use its full bundler capabilities. RSPack fully supports Vue with a config (Vue - Rspack), so your Vue app will compile successfully and still integrate with Meteor Atmosphere packages.

We will confirm the official Meteor-RSPack integration works for every Meteor skeleton and example, and begin maintaining it as the official solution.

[boomfly]

Will rspack work with coffeescript? Google search rspack coffeescript does not find this kind of plugins.

[janmp]

According to Perplexity, this should be possible. Will probably require some additional work though. But I know that @nachocodoner is not forgetting about Coffee Script
https://www.perplexity.ai/search/will-rspack-work-with-coffeesc-AMdmMC8BRKifgv5bfPHTKQ

[nachocodoner]

The goal is to explore compatibility with existing Meteor setups. So far, I’ve focused on React and Blaze and found working examples. And I know vue and others will be accomplished by direct Rspack support.

For CoffeeScript, since rspack is based on webpack, we can configure rspack.config.js to use coffee-loader. This should enable compatibility.

I’ve requested minimal example repositories to explore compatibilities with your common setups. I asked @janmp for CoffeeScript example and he provided me. I hope to test rspack integration on Meteor apps with various setups before the beta, aiming to ensure compatibility at least with the default example apps from meteor create.

[joylunow]

Great news hearing about the integration of RsPack with meteor. What would be an optimistic estimated release date?
Also, if meteor will be supporting RSPack, does that mean that an integration of angular 20 and meteor 3.4 would be possible through an RSPack plugin (for example the @nx/angular-rspack) or would there be limitations on meteor’s side?

[jorgenvatle]

Incredible stuff! I really think this addresses the primary DX pain point of working with Meteor apps.

While I would’ve loved to see Vite become a part of the Meteor build system, mainly due to the current ecosystem. RSPack does feel like a better choice for an everything-included framework like Meteor, and a huge leap for the platform.

This should open up for a lot of flexibility and allow for interoperability with build tools that weren’t hand-crafted just for Meteor.

The “UnJS (unplugin)” plugins aim to be an universal and compatible with most major build systems. And with RSPack, Meteor automatically gets to benefit from this. And hopefully the inverse as well, where it moves the JS community slightly closer to standardization within the bundler ecosystem.

I’m really excited for this!

[nachocodoner]

No release date yet. We’re focused on stability in 3.3.1 while progressing on 3.4, the Rspack bundler and Change Streams.

Like with Meteor 3.3’s SWC and other optimizations, we’ll ship several betas to test both small and large apps, address edge cases, and gather feedback. We also plan core improvements, such as dev-only packages to slim production bundles. Betas should begin at the end of July, with Rspack support beta likely in August. After the beta phase, we’ll move toward an RC and the final release.

would be possible through an RSPack plugin (for example the @nx/angular-rspack) or would there be limitations on meteor’s side?

We can try that. It should be supported, but I’m not familiar with @nx/angular-rspack. It doesn’t act as a loader or plugin for rspack.config.js and instead uses its own config approach, similar to what we plan for Meteor, so I’m not sure how it would fit. Thanks for bringing this up.

Could you share a small Angular app repo that uses Rspack? That would make it easier to test compatibility later.

[joylunow]

It doesn’t act as a loader or plugin for rspack.config.js and instead uses its own config approach, similar to what we plan for Meteor, so I’m not sure how it would fit.

From what I understand, it’s just a wrapper, so it returns a compatible RsPackOptions configuration at runtime. This is how an output would look like: Untitled (ri3sgor0) - PasteCode.io

Could you share a small Angular app repo that uses Rspack?

I’ve created a github repository with a working example using angular 20 and the latest version of rspack and @nx/angular-rspack. GitHub - Joyzyy/angular-rspack-test: rspack integration with angular 20

I’ve also tried to implement the angular rs-pack configuration over on the modern-bundler-integration branch, but to no avail. I might be misunderstanding some things about how meteor works internally (since I don’t have that much experience), so i might’ve done something wrong, that being said, these were issues I ran into:

• I’ve manged to compile the angular frontend, deploying it on port 3005, and serving the assets on the publicPath of __rspack__/, so the rspack_server can create the proxy. What i fail to understand is why there is a need for the main-client.dev.js inside the _rspack folder since in development we are using setMeteorAppCustomScriptUrl(addEnvSuffixToFilename('/__rspack__/main-client.js')); which just uses the proxy?
• Also, is it possible to add multiple script tags to the <body></body> of the generated html by meteor’s static-html plugin? Since the compilation of the angular frontend generates 6 main files: vendor.js, polyfills.js, main.js, runtime.js, styles.js, styles.css which all are needed in the index.html on localhost:3000, or can we skip the index.html generated by meteor and use the index.html generated by rspack (but using this option, how would meteor append the needed scripts (like ddp, tracker) to the index.html)?

I’m sorry in advance if some of the question don’t make any sense, didn’t get a chance to get a good look into how meteor works fully.

[nachocodoner]

I think it’s too soon to check out that branch. I haven’t even created a PR yet since it’s still in an early experimental phase. It’s not final code, it isn’t fully automated, and it doesn’t cover every config or setup scenario.

I’ve made it work: as shown in this post, a React setup with build times as a preview of what’s coming. Over the past week I’ve tested other setups on manual and local apps. I’m building an abstraction to handle different setups and configs, and I’m continuing with automation and cleanup. I’ll create a PR once it covers the abstraction and addresses basic edge cases, and I’ll explain the approach when the time is right.

Thanks for the Angular example repository. It will help me understand Angular requirements. First, we need to cover the basics of Rspack integration in Meteor. Then we can address any remaining Angular config questions and code needs, like having multiple script tags and etc, if needed.

---

From what I understand, it’s just a wrapper, so it returns a compatible RsPackOptions configuration at runtime. This is how an output would look like: Untitled (ri3sgor0) - PasteCode.io

I understand, that’s helpful. Meteor will also add a wrapper around the rspack config with its own expectations, which may conflict with the Angular config from that package. We should be able to make both configs work together and support Meteor. Let’s revisit this later.

[joylunow]

While I know the integration is not complete, I’ve patched together an implementation (tested in only dev mode) of the said @nx/angular-rspack and meteor (your branch, not 100% up-to-date) in the hopes that it helps you in the creation of the wrapper config of meteor over rspack.

Here is the repo, (which is just a proof of concept): GitHub - Joyzyy/angular-meteor-dev-rspack: implementation of angular-rspack and meteor modern-bundler-integration branch

and a video of meteor and angular working together (sorry for the low quality, had to transform from .mov to .webp to be able to upload it):

[receptim]

Maybe a bit off topic, but will version 3.4 fix the exports issue in package.json?

[nachocodoner]

Meteor 3.4 will let you optionally use the Meteor-Rspack integration mentioned in this post by adding the new rspack package. Using it unlocks many bundler features, including support for the exports field in package.json.

For projects that choose to keep the default Meteor bundler, we still need a contribution to add this feature to Meteor itself:

Resolve package.json exports

We’re open to assisting with its inclusion once it’s ready by the author, but the modern path to support it is via Rspack.

[nachocodoner]

After successfully automating Rspack in Meteor and focusing on production deployment, it’s clear that build time isn’t the only improvement coming in Meteor 3.4.

Client bundles are now thinner, meaning less code delivered and faster initial load times for your apps.

By integrating the work-in-progress Rspack package in fredmaiaarantes/simpletasks and deploying it to a private instance on Galaxy Cloud, the client bundle size dropped by about 50% compared to the 3.3.1-rc.2 release.

Gains vary by app and dependencies, could be less or much more. This comes from long-awaited tree shaking support and other optimizations. Large libraries like ChakraUI benefit the most when properly tree-shaken, and with a modern bundler, your app can now take full advantage of this optimization phase.

Besides, Rspack comes with tooling to diagnose and analyze your bundles. I’ll demo that soon once it’s properly integrated with Meteor’s bundle visualizer. After wrapping up a few things, we aim to hit the first beta sometime in August.

[awatson1978]

Any ETA on when the RSPack beta is going to be released? Are we still on track in the next couple of weeks? Super looking forward to it, and setting up a bunch of tools/projects in anticipation for it.

[nachocodoner]

No ETA yet, but we’re committed to delivering the beta as soon as possible, still aiming for August. We’re also continuing the 3.3.x series with 3.3.1, the upcoming 3.3.2, and a 2.16.2 with Cordova 14 support.

Rspack integration has automation in place. We’re building a modern test suite to ensure quality and stability over time, along with documentation outlining the basic adoption steps. We’re also reviewing other apps and project configurations to make sure the integration can handle any customized project from the Rspack ecosystem. This flexibility work will continue through the betas to ensure compatibility for everyone. Once we have the basic examples, test coverage, and docs in place, we’ll be ready for first 3.4-beta. We’ll communicate here.

[nachocodoner]

For any project that wants to adopt Rspack, start by addressing the prerequisites needed for this to work in any Meteor app.

Today I’ll mention the first one: clearly defining your Meteor app’s entry points.

Meteor apps with a modular structure can adopt the Rspack integration. Modular here means declaring the entry files that start your client and server apps, along with the tests. Your app should specify at package.json:

{
  "meteor": {
    "mainModule": {
      "client": "client/main.js",
      "server": "server/main.js"
    },
    "testModule": "tests.js"
  }
}

Learn more on “Modular application structure” in Meteor.

Before using this modular config with entrypoints (before Meteor 1.7), the Meteor bundler eagerly loaded every JS file it encountered in your project directory and constructed the booter itself. That was less efficient and didn’t match how modern bundlers work. During the Meteor 3.3 beta, some projects that sent me profiles didn’t describe their entrypoints, and I’m not sure they know how.

Describing entrypoints isn’t about creating blank files and listing them in package.json. Those entrypoints must import the rest of your app’s modules in order. An entrypoint is the first module that builds the module tree for your app, so it’s the starting point for booting it. You need to migrate your app to use this approach to use the opt-in Rspack integration.

---

Please answer the next question so we can understand your app’s state and decide whether to add more automation, documentation or guide to ensure a modular structure with clear entry points.

Do you use entry points in your Meteor app?

• Yes, my project already uses entry points for the app and tests
• No, my project doesn’t use entry points, but I know how to migrate
• No, my project doesn’t use entry points, and I don’t know how to migrate

[permb]

An entry point file for an app makes total sense but for tests it would be a big deterioration to not just include all *.tests.* files. Would it be possible to keep that mode for tests only?

[nachocodoner]

In my Meteor‑Rspack app, I first compiled each *.test.js separately by finding them and adding each as a bundler entry. That added overhead and hurt performance. I switched to a single entry point that I maintain manually with “meteor.testModule”.

I’m open to adding an automatic “virtual” entry point, limited to tests, as it only seems to require listing .tests.js files that are likely independent, and ensure watcher keeps active filling that entry point. This approach appears efficient to keep. I’ll consider it for the first beta if time allows, otherwise later.

Definitely, app entrypoints are needed, as you noted. With the app we can’t guarantee the proper load order. We could try to mimic what Meteor internals do, but that’s likely time consuming. I don’t have experience with it yet.

I also considered automatically adding entry points when a project lacks them, as @radekmie suggested here. I could automate it later, and it would help others replicate the process and migrate their apps to proper entry points.

[schlaegerz]

Yes I +1 the wanting the test files. note that there are two version .app-test and .test that are the difference between unit test files and functional test files.

It would be possible to do it manually, but its a nice piece of meteor architecture that would be annoying to lose