Support initial chunk css loading

tadhglewis commented 1 year ago

Modification Proposal

In the readme

Note that if you import CSS from your webpack entrypoint or import styles in the initial chunk, mini-css-extract-plugin will not load this CSS into the page. Please use html-webpack-plugin for automatic generation link tags or create index.html file with link tag.

From my understanding, this is explicitly not supported because you'd expect the consumer to use html-webpack-plugin so that the main.js and main.css file requests load at the same time - instead of having to load and run the JS which then requests it's own CSS.

Our use case is relatively unique where we're compiling a single JS file for use on 3rd party systems. For simplicity sakes, we want the JS file to load it's own CSS instead of the 3rd party company having to include a css tag as well as the js tag.

Expected Behavior / Situation

Initial chunk css is loaded by the JS - or at least an option/toggle is provided to enable this behaviour

Actual Behavior / Situation

Only async / non-initial chunk css is loaded

Workaround

We're currently using pnpm to patch mini-css-extract-plugin

https://github.com/webpack-contrib/mini-css-extract-plugin/blob/master/src/index.js#L1079 set to true so initial chunks can be loaded
https://github.com/webpack-contrib/mini-css-extract-plugin/blob/master/src/index.js#L954 add "Object.keys(installedCssChunks).forEach(id => loadStylesheet(id))" as installedCssChunks defaults to the initial chunks as they're assumed to be loaded by the html

This isn't super elegant so in the long term, support for this would be much appreciated - or if you had other suggestions on how can accomplish this.

alexander-akait commented 1 year ago

I don't see any reasons to load initial CSS using javascript, you will get only extra code, worse perf, style flashing, if you want to load CSS in async way you can use import(...), so what is the point?

tadhglewis commented 1 year ago

@alexander-akait For context

We have 'widgets' that 3rd party companies embed into their applications.
1. These must be as simple as possible and foolproof. This is why we tradeoff having to manually import the CSS for slower loading CSS - we have very high edge and device caching which eliminates essentially all of the style flashing except for initial loads on very slow networks/devices which isn't typical in our domain anyway.
2. We don't have control over these 3rd parties so any changes we want to make to our bundle can't introduce a change for partners - even simple changes like the CSS file name changed, it'd break business critical systems in 3rd parties and require weeks of effort to get them to fix it.
3. We can't do versioning as our partners must have the latest version at all times - also even with versioning, we still wouldn't want to introduce breaking changes in a new version
We can't do manual import('main.css') as the styles aren't expose and instead they come from our design system which uses a css-in-js approach

I understand for a traditional web app where you control everything you definitely should load the initial css and js at the same time rather than what I'm proposing here - we do this for our other products where we control the host.

However in instances where you don't control the host/html where your JS is loading, I think there's an argument to be made that JS should load it's CSS.

alexander-akait commented 1 year ago

Sorry, I don't want to change it, it is not good to change initial to async, it breaks a lot of things than you think, you can find the same questions here using search, if you want to be async, please write async code, changing the semantic is the worst idea, if you logic is very specific and you still want it (and you know what you do), you can fork a plugin and apply your changes, also you can disable runtime generation (we have an option for this) and load CSS as you want

tadhglewis commented 1 year ago

Fair enough, I had a feeling it might not be a common enough use case to fit within mini-css-extract-plugin officially however I was thinking this could be more an option rather than a fundamental change in the package🤷

Awesome work on this package by the way, super useful ❤️

alexander-akait commented 6 months ago

Closing due to inactivity. Please test with latest version and feel free to reopen if still regressions. Thanks!

vpzomtrrfrt commented 6 months ago

Regression? Isn't this a design decision?

alexander-akait commented 6 months ago

It is a design solution for mini-css-extract-plugn, anyway we are working on built-in CSS support inside webpack https://github.com/webpack/webpack/pull/18126, and we will support it

webpack-contrib / mini-css-extract-plugin