Asset management for libraries?

[filimon-danopoulos-stratsys]

I have multiple applications written in Vue that are distributed as NPM-packages. These are consumed by a host that manages the final build with Webpack.

When building the Vue-apps with Webpack (in library mode with ESM output) I use experiments: { css: true } so I get a CSS-file as part of the output. I need to make the second Webpack build in the host aware of this non-ESM asset so that it is included in the final build.

The same thing applies to other non-ESM assets too like SVGs. What is the best way to solve this issue 2025? I'm not necesarily looking for an out-of-the-box solution but I want something that scales and is not dependent on manual mapping.

The best I can think of myself is generating a manifest with webpack-assets-manifest or webpack-manifest-plugin and somehow use them in the host build to automatically copy these files to the output folder. However in this instance I would get a CSS-file per Vue app so the integration does not really optimize CSS all that well.

Any other suggestion or help is greatly appreciated. 😀

[alexander-akait]

I need to make the second Webpack build in the host aware of this non-ESM asset so that it is included in the final build.

What do you mean? Do you want analizable ESM output, so webpack again can understand about this file?

[filimon-danopoulos-stratsys]

Maybe, I am not exactly sure what the best solution for this problem is with Webpack. Since there are no module sematics left internally things like import() would also not work properly without some extra tooling.

Is there a way to make a send webpack build aware of all assets produces during the first build?

[alexander-akait]

Is there a way to make a send webpack build aware of all assets produces during the first build?

Technically yes, you can collect them using stats and ignore them (make them null) for the second build (using alises). But why do not use new URL("", import.meta.url), it will be a valid ES syntax without import CSS/SVG/etc, we have an issue about supporting new URL() syntax for CSS (with resolving url() and @import).