Prevent non-module SCSS/CSS imports in JS/TS files

[mirka]

What problem does this address?

@wordpress/wp-build inlines all imported stylesheets into the JS bundle as runtime-injected <style> elements (with data-wp-hash deduplication). This means that if someone adds import './style.scss' in a JS file, it silently "works" at runtime, making it easy to miss that this is the wrong pattern.

In most packages, stylesheets should be imported through the package's root-level style.scss, not directly in JS. Importing in JS bypasses the standard stylesheet pipeline and causes the styles to be injected at runtime via document.head.appendChild. This has several problems:

• Redundancy. If the stylesheet is already in the root style.scss chain, it gets loaded twice.
• Missing from the stylesheet bundle. If the stylesheet is not in the root chain, it's absent from the CSS file that WordPress enqueues, and only loads through the runtime injection.
• No RTL processing. Most packages rely on the build-time RTL transformation to generate -rtl.css stylesheets. Runtime-injected styles bypass this entirely, so any directional styles (margins, paddings, borders, etc.) will be broken in RTL locales.

I found three existing cases of this:

• packages/block-editor/src/components/block-visibility/modal.js imports ./style.scss. This is redundant because the same file is already in the root packages/block-editor/src/style.scss.
• packages/editor/src/components/collaborators-presence/index.tsx imports ./styles/collaborators-presence.scss, and list.tsx imports ./styles/collaborators-list.scss. These are not in the root stylesheet at all, so they're only loaded through the runtime injection.

What is your proposed solution?

1. Fix the existing cases. Remove the SCSS imports from the JS/TS files above. For the collaborators-presence stylesheets, also add them to packages/editor/src/style.scss.

2. Add a lint rule to prevent importing non-module .scss/.css files in JS/TS files. This should flag side-effect-only imports like import './style.scss' while allowing CSS module imports that have a binding (e.g., import styles from './style.module.scss'). The rule should apply to packages that use the root-stylesheet convention, and could be configured via an .eslintrc.js override to exclude packages like @wordpress/ui that intentionally import styles in JS.

3. Consider restricting wp-build inline injection to CSS modules only. Currently the compileInlineStyle transform in wp-build processes all .css/.scss imports the same way. If it only applied the runtime injection to .module.css/.module.scss files, developers would notice that the styles are missing.

[mirka]

@jsnajdr What do you think about solution 3? Was there any intentionality to the fact that we don't restrict the inlining behavior to CSS modules?

[jsnajdr]

So the rule would be like the following?

• import 'style.scss' statements in JS code are allowed only for CSS modules that ensure that the class names are mangled and unique.
• non-mangled, global styles are not allowed as JS imports at all. Such styles must be in a stylesheet that's explicity exported by a package as CSS, like @wordpress/block-editor/style.css, and such styles are supposed to be loaded with wp_enqueue_style.

Why not, but we need to ensure that this rule is really universal, both for Gutenberg and also all the 3rd party plugins that use wp-build.

At this moment, import 'style.scss' is used at many places in Gutenberg that use the "new WP Admin routing framework", or how to call it. For example, there is this style import in routes/post-list:

https://github.com/WordPress/gutenberg/blob/trunk/routes/post-list/stage.tsx#L51

It defines class names like dataviews-action-modal__quick-edit or routes-post-list__tabs-wrapper that are then used in post-list JSX markup. There are 20+ usages in routes/* and packages/boot, mostly added by @youknowriad. Should they be all migrated to CSS modules? Looks like a good idea to me.

Then we have imports like this one in packages/notices:

https://github.com/WordPress/gutenberg/blob/trunk/packages/notices/src/components/inline-notices/index.tsx#L17

Because wp-notices is a registered script, this usage looks like one of the bugs you want to fix and avoid with this PR, is that right? The styles in question override the components-notice style from wp-components, which is probably completely unwanted. And if the style was wanted, it should be a stylesheet exported by the @wordpress/notices package and registered with wp_enqueue_style( 'wp-notices' ).