feat: global CSS loader

[Haprog]

This makes it so that you can import a CSS file into document scope with an import like:

import './about-view.global.css';

(using a *.global.css filename suffix)
instead of needing something like:

import '!style-loader!css-loader!./about-view.css';

It also makes it so that using a CssResult imported like:

import styles from './my-component.css';

will show a deprecation warning (based on an update to types.d.ts).
To avoid the deprecation and future proof your import you need to use a filename suffix *.shadow.css when you need to import a CSS file as a CssResult like this:

import styles from './my-component.shadow.css';

It's intended that in the next major version (after this has been released) the default behaviour for *.css will change so that you no longer need the .global.css suffix to import styles to document scope but keeping global in the filename will still keep working.

Closes #9970

[Haprog]

If this gets merged, some documentation probably needs to be added to the docs repo about this.

[Haprog]

I just tested this snapshot (<flow.version>7.0.global-css-loader-SNAPSHOT</flow.version>) (using same version for flow-maven-plugin) and it seems to work as intended without any obvious problems except if you have an existing project you need to delete types.d.ts so that it gets updated since we have no upgrade mechanism for it (otherwise you don't get the deprecation behaviour).

[haijian-vaadin]

Just tried, it works as described, great job!
One thing I think could be improved is that when using import styles from './main-view.css';, I only see a warning when trying to use styles, and it doesn't tell what to do.
First, could we show the deprecation warning for the import line instead of when trying to use styles?
Then could it have more information like xxx is deprecated, please use xxx.shadow.css instead?

[Haprog]

First, could we show the deprecation warning for the import line instead of when trying to use styles?

I'm not sure if this is somehow possible.

I can try if adding a note to the deprecation comment in types.d.ts shows it as a deprecation message. That's a good idea if we can show that you should use the shadow suffix instead.

[Haprog]

Added a deprecation message description. See screenshot:

It's also shown if you hover over styles on the import line but unfortunately it doesn't highlight the word styles with a strike-through on that line as it does in usages.

Seems like that could be fixed later in the IDE itself or some related IDE plugin.

[Haprog]

TeamCity build failed probably due to the scheduled service outage. Let's retry the build a bit later.

[marcushellberg]

After trying alternatives locally, I ended up preferring query strings to determine how a file is loaded, instead of the filename. That way, the user can determine in each case how they want to load a file.

For example, let's say someone has a small shared.css that they want to load globally. They can do import "./shared.css" or import "./shared.css?global". But they could also load that into a shadow root as a CssResult with import "./shared.css?shadow".

If the filename determines how the file is loaded, the person in the above example would need to create two files with the same content to achieve their use case.

[haijian-vaadin]

Decided to use filename convention over URL suffixes based on the reasons below:
CSS contents are never independent of their usage, but are rather always bound to some area of the application. The context of usage needs to be defined already when creating a CSS file, at least in the author’s mind — it is essential to know which selectors to use.
When you have a separate CSS file, and the file path does not tell whether it is applied to shadow roots or document styles, it’s a DX issue.
It is even more important for the future maintainer to be able to tell what CSS was for. Consider using a global file content search when maintaining CSS in a large project (often the only tool available). Filename convention makes it easier to confine the search in the certain type of CSS (only shadow or only document).
CSS for both document and shadow roots is an anti-pattern that should be avoided. It never yields efficient and maintainable CSS, unless you really know that you’re building a custom design system.