Size Change: +1.14 kB (+0.02%)

Total Size: 6.84 MB

_{compressed-size-action}

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: mirka <0mirka00@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: ciampo <mciampini@git.wordpress.org>
Co-authored-by: aduth <aduth@git.wordpress.org>
Co-authored-by: ellatrix <ellatrix@git.wordpress.org>

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

I wonder if the JavaScript part of this is overkill for what we could potentially manage ourselves. Specifically, I'm a little concerned of the performance impact of reading full contents and scanning for --wpds- of every single JavaScript file included or depended by the project.

If we did decide to keep the JavaScript pieces, is it necessary to have a dedicated Vite plugin if Vite internally uses ESBuild (i.e. can we tell it to use the ESBuild plugin).

Another option could be to generate these out-of-band to check into source control, similar to what we do with theme artifacts and checking their accuracy.

Upsides:

• We can check the output to make sure it's accurate
• No overhead for "normal" Gutenberg development
• Doesn't have to be part of the main build? Could be more targeted at these files specifically, managed through package scripts

Downsides:

• Additional maintenance overhead for us
• Feedback of being out-of-sync is late (CI failure)

One question regardless of approach is whether we should be more targeted to @wordpress/ui styles more specifically?

To first give an idea of the measured build performance impact:

• New Terrazzo plugin — negligible
• Vite plugin — negligible
• PostCSS plugin — negligible
• esbuild plugin — negligible (there’s a redundant readFile for non-matching files, but the files are apparently already in the OS cache by then, so there’s no measurable overhead)

If we did decide to keep the JavaScript pieces, is it necessary to have a dedicated Vite plugin if Vite internally uses ESBuild

Yes, apparently Vite cannot use esbuild plugins directly 🙃

One question regardless of approach is whether we should be more targeted to @wordpress/ui styles more specifically?

My understanding was that at least @wordpress/dataviews would also need to be targeted, as another bundled package using design tokens directly. I also thought it’d be necessary for plugin developers to have these transformers available in their standard build tooling, otherwise they won’t be able to use tokens in their own code for a while.

If we did selective replacement (either of certain packages or of certain file types), we’d also need to add linters to warn on token usage that isn’t going to be replaced. So given that kind of added complexity (and missed spot risk) of selective replacement, the negligible overhead of the “replace everything” strategy doesn’t seem too bad.

What do you think? If there are still some reservations about certain parts of the flow, I think it’s fine to start small (like just the stylesheets). But performance-wise, it seems pretty much free.

If it's in-fact negligible, then I'm not as concerned. We could choose to scope it if it turns out to be an issue.

Something we discussed while pairing on this that's worth considering: Do we even need the default stylesheet if we have this fallback behavior in place? It could be problematic for downstream consumers that want to use theme tokens, but then they could also just opt to use the same plugins we're developing here for our own build pipeline.

cc @youknowriad since this impacts the build scripts, and following some previous discussions about integrating theme variables. For visibility, this builds on #75586 which adds approximate values for theme variables to be used as fallbacks.

As described in #75586, this is largely meant to be used for backwards-compatibility, since plugins may support 2-3 or more versions of WordPress, the components still need to work. The approximates are very rough and ThemeProvider is still the preferred means of generating color values. This is just meant to ensure the components can be basically functional and themed in an environment where that's not available. We could probably even remove the fallbacks behavior after a few versions.

Does the fallback honor the WordPress user profile? What's the story for that?

Does the fallback honor the WordPress user profile? What's the story for that?

Yes 👍 We have a story to check the wp-admin-theme-color-related fallbacks (see video here).

Ok sounds good to me. You folks know better than me here.

Not sure if this is the expected behaviour, but I'm testing Gutenberg locally, and dataview UI doesn't seem to have fallbacks applied — neither for @wordpress/ui components (ie Stack), nor for direct tokens usage:

@ciampo Thanks for catching. One was that it was only processing CSS modules, and the other was that Stack was generating CSS variable names dynamically by interpolation. Dynamic CSS variable names will continue to be a footgun that needs to be avoided, as it circumvents all linting.

I checked for any other possible gaps that we're missing, but couldn't find any. Would appreciate more eyes (tokens 😐) here though.

#75879 is the other important half of the fix for https://core.trac.wordpress.org/ticket/64698, where we actually remove the design tokens stylesheet from being exposed through a style handle and loaded in the app.

Flaky tests detected in 0e64b79.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/22365458408
📝 Reported issues:

• [Flaky Test] can be replaced by dragging-and-dropping images from the inserter #50325 in /test/e2e/specs/editor/blocks/image.spec.js

There was a conflict while trying to cherry-pick the commit to the wp/7.0 branch. Please resolve the conflict manually and create a PR to the wp/7.0 branch.

PRs to wp/7.0 are similar to PRs to trunk, but you should base your PR on the wp/7.0 branch instead of trunk.

# Checkout the wp/7.0 branch instead of trunk.
git checkout wp/7.0

# Create a new branch for your PR.
git checkout -b my-branch

# Cherry-pick the commit.
git cherry-pick 17f3eb354afdc12cd8ea814b4480411228f0e1bf

# Check which files have conflicts.
git status

# Resolve the conflict...
# Add the resolved files to the staging area.
git status
git add .
git cherry-pick --continue

# Push the branch to the repository
git push origin my-branch

# Create a PR and set the base to the wp/7.0 branch.
# See https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request.

Manually cherry picked at #75901

Stack was generating CSS variable names dynamically by interpolation. Dynamic CSS variable names will continue to be a footgun that needs to be avoided, as it circumvents all linting.

Improved the token validity lint rule in #75905 to prevent these cases.

When manually cherry-picked, the labels should be updated manually as well