hey I stumbled onto this, admittedly its my agent who tells me there is nothing wrong our side, so I might be wrong. I searched myself around the docs but couldnt find anything. we tried to exclude them from rspack manually and compile with meteor bundler but the site doesnt load then
What I want to do is dynamically load html fragments when the user navigates to pages. If i understand right now all the html templates are bundled by rspack and shipped to the client.
opened 09:33PM - 29 Sep 26 UTC
modern-build-stack
We use Meteor 3.5.2, rspack@1.3.0, @meteorjs/rspack@2.2.0, and Blaze with Flow R… outer Extra on Linux. A route dynamically imports its controller, which imports its paired
HTML:
```js
// Route
waitOn() {
return import('/imports/ui/pages/tagged-with-page.js');
}
// tagged-with-page.js
import './tagged-with-page.html';
```
The controller is loaded on demand, but the compiled template is in Meteor’s initial app/app.js. On an unrelated /login visit, Template.tagged_with_page is already registered.
In the installed integration, Rspack ignores .html and RequireExternalsPlugin eagerly links HTML imports into Meteor’s startup entry. It appears that Rspack’s import()/splitChunks therefore cannot split the compiled templates.
1. Is there a supported way today to load the compiled Blaze template when the route’s controller is imported?
2. Does meteor.modules only select files for Meteor compilation, rather than make those templates lazy?
3. If this is not supported, would route-lazy compiled Blaze HTML fit the Meteor–Rspack roadmap? What integration point would be appropriate?
This is a question/feature request, not a bug report: I don’t have a last-known-working Meteor version or a public minimal reproduction. I found the
earlier Blaze template code-splitting discussion (https://github.com/meteor/blaze/issues/100), but this question concerns the current Meteor–Rspack
build boundary.
Thank you for reporting another edge case for Blaze.
As part of Meteor 3.6, we have covered a bunch of new failure cases, and this is yet another one. We really need your help to get Blaze into a properly covered state, so thank you for showing up and reporting the problem in detail.
Thanks to that, we have been able to cover this edge case with dynamic imports in our E2E suite and fix it:
release-3.6 ← test/14803-blaze-lazy-import
opened 03:34PM - 30 Sep 26 UTC
This PR fixes lazy Blaze template imports with Rspack for `release-3.6`. When a … FlowRouter route dynamically imports its controller, the controller's paired HTML now stays lazy and is ready before the controller executes.
Fixes [#14803](https://github.com/meteor/meteor/issues/14803).
I reproduced the issue with FlowRouter's `waitOn()` importing a controller that imports `./tagged-with-page.html`. The default Meteor bundler already handles this correctly. With Rspack, the controller was lazy, but the HTML was still downloaded and registered at startup because the integration mirrored every HTML import into Meteor's eager entry.
The fix keeps Blaze compilation in Meteor and connects Meteor's existing dynamic-import loader to Rspack's chunk-loading hooks. Rspack tracks the HTML dependencies of each chunk and waits for them before evaluating the controller. The compiled templates are fetched through Meteor's dynamic-import payloads alongside the Rspack JavaScript chunk, using Meteor's existing cache. Templates used by the initial app remain eager, including those shared with a lazy route.
Also, generated imports now keep their configured order across rebuilds and upgrades, so the template module stays before the app bundle. In development, Meteor handles the page reload after recompiling the templates, including JavaScript-only changes. This avoids reloading against mismatched JavaScript and templates.
The new E2Es check the initial scripts actually downloaded by the browser, template registration before navigation, and template availability when the controller executes. They cover the default bundler and Rspack in development and production, a built Rspack app, and eager-to-lazy transitions during development rebuilds. The existing router import-order assertion follows the generated template module and still checks that templates load before the app bundle.
Validation with the local `@meteorjs/rspack` package linked:
- All 31 Blaze E2E checks passed in Chromium with retries disabled: 26 existing checks and five new dynamic-import cases.
- All three new unit checks passed, covering import order as dependencies change, upgrades of existing generated entries, and preservation of the last working entry when compilation fails.
- The E2E group audit and whitespace checks passed.
```bash
METEOR_E2E_TEST_RETRIES=0 npm run test:e2e:group -- blaze
npm run test:unit -- npm-packages/meteor-rspack/plugins/RequireExtenalsPlugin.test.js
git diff --check
```
For the local run, the skeleton suite used a temporary free port because its default port was occupied. That test-only change was restored afterward.
The package README and E2E coverage report are updated. `@meteorjs/rspack` will need a release for applications to pick up this fix.
We will likely be able to include this fix in the Meteor 3.6 or otherwise 3.6.1 patch, since we have already closed the Meteor 3.6 beta for features or critical changes . I will see if the changes above are stable enough to be added straight.
Btw, we will introduce Blaze 3.1.0 support as part of Meteor 3.7, so we really need more eyes and hands testing it on real Blaze projects.
@nachocodoner amazing thank you for the quick fix