CSS chunks from dynamically imported JS files? lazy loading CSS chunks?

[rcherny]

Background: Lazy CSS Chunks:

So I've found, tested, and can implement the pattern from the readme and the js-import-css-lazy-url test case:

import cssUrl from './style-dynamic.scss?url';

I've even extended that for Constructable Stylesheets using fetch() + document.adoptedStyleSheets. It works well. Thanks!

(A) Question one: Can we get the CSS source?

Constructable stylesheets allow injecting the source. I guess similar to the style-loader approach — which we never use — but this could be useful with Constructable Stylesheets.

Question 1: Is there a way to get the CSS source from the above pattern as opposed to just the URL? I was looking for ?source or something, and considered testing ?inline, but I figured it may not work. Perhaps directly using require(...)?

(B) Question two: CSS Chunks from Dynamically imported JS files seem missing...without ?url and member name

Our code base is a large SPA, and per route we lazy load files. We split up loads for performance vs the initial render.

The first thing I've noticed is that the plugin doesn't seem to generate a CSS chunk for CSS files that are imported inside a JS file loaded via a dynamic import statement, unless the ?url pattern is used, and you must use the member name:

/* file one.js */
import('./two.js');

/* file two.js */
import './style.css'; // does not generate a file
import './style2.css?url'; // does not generate a file

// html-bundler-webpack-plugin does not generate a chunk
// however, using this pattern, it does
import css from './style.css?url'; // does generate a file

I considered opening a bug issue report about that, but will wait until I know more about this and run additional tests.

Small Aside

I also happened to notice, that either by design or coincidence/happenstance, that this seems to NOT work if called:

// does not work
const loadStyles = () =>
  import('Foo/styles/index.scss');

// nor does this
const loadStyles = () =>
  import('Foo/styles/index.scss?url');

This works with the MiniCssExtractPlugin just fine as well. This does work if you use a lazyLoad() function instead, however.

➔ It would be really great if any css import statement with ?url or ?lazy generated a chunk and it was left up to the developer on how to use it.

(C) Question three: CSS only imports?

At any rate, dynamic CSS and routes was a main use case for us with the MiniCssExtractPlugin, and we also leveraged the webpack-remove-empty-scripts plugin. This recently stopped working on our build for whatever reason and now we are getting JS files that do nothing but load a CSS file, which is super sub-optimal.

This set up allowed us to have a JS file that effectively was dropped and the dependency was just a CSS file.

While this isn't our precise use case, it's similar to where things are headed with:

1. CSS Module Scripts
2. Native CSS Support

With item 2 above, I was hoping to enable experiments.css and use it along side html-bundler-webpack-plugin, but when I did, there were errors ... I saw in cssLoaders.js a reference to experiments.css — is there something specific that I need to do in order to get this to work?

[rcherny]

So the other issue I've run into is that so far our Jest tests and Storybook configurations don't care for this syntax:

import css from './style.css?url';

This may work with experiments.css but only if I can get that working with the bundler. I'll post back if I make any progress.

[webdiscus]

Hello @rcherny

Question A

I can't influence everything that happens in JS. Webpack self compiles JS. Using a loader I can only influence on a content of a file matching to webpack rules.
So, you can't get generated CSS source directly in JS where was imported a style file.

require vs import for webpack doesn't matter, the generate only corresponding inner object structure for CJS or ESM syntax.

[webdiscus]

Question B

Using the dynamic import like import('./component-a.js') generate no CSS files for styles imported in the nested JS.
Yes, I can reproduce it.

Is it a bug? No, it's yet not implemented feature ;-)

[webdiscus]

@rcherny

In the version 3.9.0 following use case is fixed:

file one.js

// dynamic import
import('./two.js');

file two.js

import './style.css'; // <= FIXED, generates a CSS file

[webdiscus]

@rcherny

In the version 3.9.0 added support for dynamic import of styles:

// dynamic import
const loadStyles = () => import('./component.scss');
loadStyles(); // generates a CSS file

[rcherny]

I really appreciate all the effort. When I push my test repo I'll include these tests and include an example.

Great stuff!!

[webdiscus]

At any rate, dynamic CSS and routes was a main use case for us with the MiniCssExtractPlugin, and we also leveraged the webpack-remove-empty-scripts plugin. This recently stopped working on our build for whatever reason and now we are getting JS files that do nothing but load a CSS file, which is super sub-optimal.
This set up allowed us to have a JS file that effectively was dropped and the dependency was just a CSS file.

Please create an issue by webpack-remove-empty-scripts (last update 2023-08-28) and a small repo with reproducible issue (in some case empty JS file will be not removed)

[rcherny]

Working on a test repo. Will try to push by tomorrow sometime. I've run out of computer time for the moment.

I inherited the prod repo in question that implemented the remove scripts plugin. I may have misunderstood something about it. Does it only remove scripts for CSS that are entry points? (realizing this should be all asked over there, lol)

I may have to just change our implementation to import() the css directly 🤔

[webdiscus]

webpack-remove-empty-scripts removes only JS, that will be "automatically" created for CSS defined in the entry option.
If any JS was defined in the entry option, this JS will not be removed.

[rcherny]

Understood. I believe I misunderstood that the remove empty scripts plugin would remove any JS module files that only had a CSS import. It's just for entry points. Now I understand this.

[webdiscus]

Question C

Currently the plugin doesn't support webpack experimental features, like experiments.css.
In cssLoader.js is only a reserved "placeholder" for the feature that will be released in webpack 6.

[rcherny]

@webdiscus So just to clarify, will there be no support for "native css" in this plugin until Webpack 6? Or is the wait at present just to be sure that webpack/webpack#14893 is more complete? I have been testing some of those features, and it certainly lacks a few key parts thus far.

[webdiscus]

no "native css" will be supported until Webpack 6. It makes no sense, because this feature is experimental and I don't will invest my time in an "alfa" feature what can be changed every time.
Otherwise, the "native css" of Webpack 6 replaces just the "css-loader" only, but not the inner cssLoader of the bundler plugin. The bundler plugin works with "own" inner css-loader what will be used always, and in Webpack 6 too.

[rcherny]

Thank you, I understand completely. I was asking for planning purposes on our side :)

[webdiscus]

For users of the plugin will be nothing changed. If Webpack 6 releases the "native css", then my plugin can automatically set the needed Webpack settings. For the end-user it will be absolut transparently, nothing will be required.

[rcherny]

Really appreciate all the follow up on this. I've had a super hectic week and I'm going on vacation this coming week; so I'll follow up more when I return. Thanks again!