At most, add a flag in the core to opt in to that CopyRspackPlugin config so you can enable it in your image,
As noted above, Meteor 3.4-beta.13 will add a new override file: rspack.config.override.<extension>, where <extension> matches your project’s rspack.config.<extension>.
If this file exists, its overrides and extensions apply to all configs, similar to the project root. This makes it easy for environments to provide their own aside the app’s config. For example, you can add the override below to your container image to apply custom rules to all apps using it.
const { defineConfig } = require("@meteorjs/rspack");
const rspack = require("@rspack/core");
module.exports = defineConfig((Meteor) => {
return {
plugins: [
new rspack.CopyRspackPlugin({
patterns: [
{
from: "public",
to: ".",
noErrorOnMissing: true,
},
],
}),
],
};
});
This still seems a workaround for your issue, but hopefully at some point in the future we can understand the root issue, maybe others will hit it soon in other circumstances we can hunt down over time. At least with this solution we don’t need to add CopyRspackPlugin for everyone or pay the performance cost of extra config.
I’ll update here when it’s ready to test for everyone. The implementation and tests are already in place.
Btw, if the issue with assets only happens as part of build, you don’t need to include CopyRspackPlugin in development mode. You can add it only when Meteor.isBuild is true, and save the overconfig. So you could do something like this:
plugins: [
Meteor.isBuild && new rspack.CopyRspackPlugin({
patterns: [
{
from: "public",
to: ".",
noErrorOnMissing: true,
},
],
}),
].filter(Boolean),
For 3.4-beta.13 I have one issue affecting the local package case reported by @storyteller. If a quick fix isn’t possible (for the moment no luck on fixing it), I’ll postpone it or provide a workaround, since it’s an edge case.