Admin UI: Add CSS files to sideEffects array

[dhasilva]

What?

Closes #76606

Why?

To avoid CSS file imports from the admin-ui package being ignored.

How?

By adding an array to the sideEffects value containing CSS files.

Testing Instructions

This one is tricky to test. I'm using https://github.com/dhasilva/minimal-wp-build-test/tree/test/admin-ui-side-effects to test this.

• Clone the repo above and checkout the test/admin-ui-side-effects branch
• pnpm install
• pnpm run build, you should see the errors shown in Admin UI: CSS imports are ignored due to sideEffects set to false #76606
• Manually edit the package.json files of the admin-ui package to be the same as this PR. In my environment, they are located in:
  1. node_modules/@wordpress/admin-ui/package.json
  2. routes/root/node_modules/@wordpress/admin-ui/package.json
  3. routes/root/node_modules/.pnpm/@WordPress+admin-ui@1.9.0_@emotion+is-prop-valid@1.4.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/@wordpress/admin-ui/package.json
  4. node_modules/.pnpm/@WordPress+admin-ui@1.9.0_@emotion+is-prop-valid@1.4.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/@wordpress/admin-ui/package.json
• Run pnpm run build again
• Check that the warning messages are gone

Testing Instructions for Keyboard

Screenshots or screencast

Before	After

Use of AI Tools

No AI tool used.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: dhasilva <thehenridev@git.wordpress.org>
Co-authored-by: jsnajdr <jsnajdr@git.wordpress.org>
Co-authored-by: CGastrell <cgastrell@git.wordpress.org>
Co-authored-by: enejb <enej@git.wordpress.org>
Co-authored-by: ciampo <mciampini@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[enejb]

I was able to test and this change make sure that the build is successful.

See
Before:

After:

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Required label: Any label starting with [Type].
• Labels found: .

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[ciampo]

I don't have much knowledge on these aspects of the repo. I will note that some packages apply the same side effects options, but, for example, @wordpress/dataviews doesn't.

Which makes me wonder what's the right move here. @youknowriad , @aduth, @tyxla or @jsnajdr maybe?

[jsnajdr]

Yes, this is a good idea 🙂

[jsnajdr]

some packages apply the same side effects options, but, for example, @wordpress/dataviews doesn't.

We should fix the dataviews package, too. Otherwise an import like this:

import '@wordpress/dataviews/build-style/style.css';

might get eliminated by a bundler.

[CGastrell]

LGTM! The fix works exactly as described.

[CGastrell]

Failing check doesn't seem related to this PR

[jsnajdr]

Failing check doesn't seem related to this PR

Yes, the e2e failures look like something that was broken in trunk last week, around the time when you created the PR, and has been fixed in the meantime.

[aduth]

I'm confused by this containing both source files as well as the built artifacts, though I guess it stems from a general confusion about how styles are meant to be brought in with this package.

• If styles are meant to be imported automatically through importing JavaScript, I'd expect we'd only need src/ here and the /build-style/ entrypoint should be removed
• Vice-versa, if someone should be expected to import the stylesheet explicitly, I'd expect we'd only need build-style/ here and the .scss import should be removed from the JavaScript code

[aduth]

I wonder if it's also wrong that we define sideEffects: false for @wordpress/ui? 🤔 I can't recall if we discussed this anywhere, or if the way that @wordpress/build works handles this in a way that's a non-concern.

gutenberg/packages/ui/package.json

Line 44 in 4eeb1d5

"sideEffects": false,

[ciampo]

To recap, it looks like there is some follow-up work to be done:

• Clarify if we need to list both source and build files in the sideEffects (comment)
• Apply the same fix to @wordpress/dataviews (comment)
• Potentially apply the same fix to @wordpress/ui (comment) ?

I don't have deep knowledge on the styles build pipeline, but at least this recap may help with future iterations.