Repository navigation
Paint the review, update and mail dialogs with the design system's tokens - #608
Merged
Merged
Conversation
…kens Part 3 of replacing hardcoded colours (#557). The three dialogs still on the older library keep their frames and controls; what was drawn by hand inside them is now the design system's: - The diff is on the strong surface inside a hairline, and its added, removed, hunk, meta and header lines are classes painted with tokens. - The boxes that warned, failed or informed are notices; the lines that said how something went are text in one of three shared classes, which also replace the apply card's and the details sidebar's own copies. - Destinations are stacks and text inside a card per group, and the update question's two answers, its file list and the mail's panes are classes. No inline style and no colour value is left in the renderer's components, and the margin every button in an older dialog was given is gone with them. Journeys assert the colours against the tokens: the diff's lines, the save's outcome, the chosen answer's ring, the raw mail's surface. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…size, and one red for what went wrong Review fix-ups. On the pressed answer's tint the quiet text colour fell under 4.5:1, so its detail is in the full text colour there. Four links that stand alone in a destination are small text again. `.error-text` is the red `.problem-text` is, not the near-black its token gave it. The test helper refuses a token the window does not have, and the mail journey no longer asks for a colour the dialog would have given anyway. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Second review pass. The rule that keeps it red wins on source order alone, so a journey asserts it: swapping the two rules turns the journey red. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
zaerl
added a commit
that referenced
this pull request
Oct 4, 2026
…r's components (#609) ## Why Parts 1 to 3 of item 9 in #557 left no colour value and no inline `style` in any component under `src/renderer`: the window is painted from classes in `src/renderer/shell.css` with the design system's tokens. Nothing stopped one coming back. A colour typed into a component is one the theme cannot reach, and `TESTING.md` rules out the only other check, a test that reads a component's source. ## What changes Two lint rules of this repository's own, switched on for `src/renderer/**/*.{js,jsx,cjs}`: - **`toolkit/no-hardcoded-colors`** reports a colour written out in a string or in the fixed part of a template: a hex value of 3, 4, 6 or 8 digits, or a function that takes a colour's channels (`rgb()`, `hsl()`, `oklch()`, `color()` and the like). A token wrapped in `var()` passes, and so does `color-mix()` of tokens. - **`toolkit/no-inline-styles`** reports a `style` attribute on a JSX element. They live in `eslint-rules/`, registered as a local plugin in `eslint.config.mjs`. No new dependency: the rules are plain modules, tested with ESLint's own `RuleTester`. **Not in this PR:** - **The stylesheet.** `shell.css` is not checked by these rules, and it is where all the styling now is. That is the next pull request: Stylelint with the design system's own rules. - A colour's name (`red`, `white`), a colour put together from pieces, a `style` passed in a spread or set from an effect. Each rule's header says what it does not read. None of these exists in the renderer today. - `src/main.js`, whose patch window still carries a few inline colours. It is not the renderer. ## How to test this Platforms: any. No user-visible surface; this is lint and its tests. From the repository root, after `npm ci`: ``` npm run lint node --test tests/unit/eslint-rules.test.cjs ``` Both pass. To see the rules bite, add `style={{ borderColor: "#dcdcde" }}` to any element in `src/renderer/components/destination.jsx` and run `npx eslint src/renderer`: it reports the inline style and the colour. I did that, and the same with an `rgb()` in `src/renderer/terminal-theme.cjs`. `tests/unit/eslint-rules.test.cjs` runs each rule over code that must pass and code that must not. I removed each guard in the two patterns in turn (the lookbehinds, the lookahead, the case flag, the string-only check, reading a template as the program gets it, `color()` in the list) and the suite went red every time. **What must not have happened:** the rules must not fire on anything in the tree as it is (`npm run lint` is clean with no disable comment added), and `eslint-rules/` must not be packaged into the app (`build.files` in `package.json` does not include it). ## Risks and limitations - Review: 2 passes, 9 findings fixed here, 1 kept as it is. Details below. - **A reference of three or four digits written out in a string reads as a colour**: `'Fixed in #607'` is reported, because `#607` is a grey and `#000` must not pass. Nothing in the tree does this; the renderer builds such strings from the number (`#%d`, `#${ n }`), and the message says so. A fragment made only of hex letters, `'#add'`, is reported too unless it follows a word or a slash. - Kept: these could have been three selectors given to the core rule `no-restricted-syntax`, with no rule files. They are rules of their own because the colour rule's message names what it found and the patterns are tested by themselves. ## Related Part of #557, after #605, #606 and #608. --- <details> <summary>Review outcome (required — see AGENTS.md)</summary> **Pass 1: 5 [fix here] · 1 [follow-up]. Pass 2 (on the fix-up): 4 [fix here]. 9 fixed, 1 kept.** - **Review:** completed — a separate agent context, read-only; head `e8903a2` / base `5b7e1fb`; ran the test file on Node and on Electron's Node, eslint over the renderer, and probed both rules with throwaway code; 5 [fix here], 1 [follow-up]. - Fixed: a test that passed without the guard it named; the header claiming a written-out reference could not be flagged; a fragment after a slash being flagged; four wordings that claimed more than the code does (the `TESTING.md` sentence, both messages, the rule's description). - Fixed though marked follow-up: tests for uppercase hex, hex after `:` and `(`, a template that cannot be read, a namespaced attribute. - Kept: custom rules over `no-restricted-syntax`, with the reason now in each header. - **Review:** completed — a second separate agent context, read-only; head `022aebf` / base `5b7e1fb`; removed each guard in memory and re-ran the suite; 4 [fix here], all fixed. - Three guards could be removed with the suite still green; two now have a test, and the third decided nothing and is gone. - Two comments named the wrong case as pinning the string-only check. - `color()` and `device-cmyk()` were missing from the functions the rule reads. - One of the two reasons given for a custom style rule did not hold. - **Since review:** `022aebf → b9bc2e2` is those four fixes only; the test file, `npm test`, `npm run test:electron` and `npm run lint` re-run on it. </details> <details> <summary>Implementation notes</summary> - The preset from `@wordpress/eslint-plugin` does not configure `no-restricted-syntax`, so nothing is overridden either way. - `RuleTester` is given `node:test`'s `describe` and `it`, so a failing case fails `npm test`; checked with a deliberately wrong case. - The journeys and the packaged smoke were not run: nothing under `src/` or `tests/e2e/` changes. </details> Nothing on screen changes, so there are no screenshots. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
zaerl
added a commit
that referenced
this pull request
Oct 5, 2026
## Why #542 replaces the app's interface with the one in the [prototype](https://github.com/jameskoster/wordpress-contributor-toolkit-prototype), drawn with the WordPress Design System. It was built in slices on `redesign/wpds`, so that trunk, which releases are cut from, never held a half-redesigned window. The window is whole now: the shell, the page header and details, every card and dialog, and the tray. This pull request is how the branch reaches trunk. It lands before the last three sub-issues, on purpose. The settings dialog (#559) and dark mode (#560) add to a finished window and do not need a branch to hide in, and the guide (#561) is easier to rewrite against what is on trunk. They follow as pull requests against trunk. ## What changes Everything `redesign/wpds` holds; this pull request adds nothing of its own. Each slice was reviewed in its own pull request against that branch, and says there how to test it and what it leaves out. - **The shell** (#555): a sites list, the page area and a footer, in a larger window. #590 - **The page header and the details** (#556): the site's menu in the header, and what the checkout is in a sidebar that can be put away. #594 - **The site's page** (#557): the server and the build watch in the header and the details (#595); the ticket card, the apply card with a preview dialog, and the list of a site's tickets (#596, #597, #599); the create-site, rename and delete dialogs (#600, #601); confirmations as notices in the window's corner (#602); the page's notices, update card and setup checklist (#605); the terminal, logs, mail and the review dialogs painted with the design system's tokens (#606, #608); and lint rules that keep it so (#609, #610). - **The tray** (#558): along the bottom of the window, holding the terminal, the logs or the mail, with a count of unseen debug.log lines on the footer (#612, #613, #614, #615). - Along the way: #611 (the site menu's update item says why it is held), and three that tidy up before landing: #616 (a journey's race with the page's clock), #617 (comments the finished redesign made untrue) and #618 (the server's button by its present name in `AGENTS.md`). **What a contributor will notice first:** the terminal, the logs and the mail are no longer on the page but behind three buttons at the foot of the window; the terminal is dark text on light; the server and the build watch are started from the header; a patch is previewed in a dialog before it is applied; and what worked is said in the window's corner. **Not in this pull request:** - The settings dialog (#559). Until it, nothing about how the window is arranged is remembered across restarts: the details, the tray's height, the apply card's fold. - Dark mode (#560). The terminal reads its colours once, when it is made, and will need to follow the theme. - The user guide and its screenshots (#561), which describe the old interface. They are published from release tags, so they are not wrong until a release ships this; #561 is next, ahead of #559 and #560, for that reason. - How a mail is drawn, and how the window handles a link. Both are unchanged and tracked separately. ## How to test this Platforms: macOS and Windows, both. Buildkite builds signed artifacts for this pull request; use the build for its current head, and check that it is: a push to the branch makes earlier builds stale. The suite, from the repository root, after `npm ci`: ``` npm run lint npm test npm run test:e2e ``` 113 journeys walk every slice on macOS and Windows on each push. What they do not do is run a real site: a clone of `wordpress-develop`, an install, a build and a server are stood in for. The one test that does, `real-setup.yml`, is run by hand and was run on this branch at `548c020` (https://github.com/WordPress/contributor-toolkit/actions/runs/37298667056): a Core site on macOS and on Windows and a Gutenberg site on macOS were created, installed, built and served, and passed. **The Gutenberg site on Windows did not finish.** Its first attempt was cancelled after 74 minutes inside the journey, a minute short of the limit that would have failed it with evidence, so it says nothing about where it was; a second attempt was still running when this was written and its result is not in this description. The commits since `548c020` change a journey, comments and prose. **A pass by hand, on a real machine** (any platform; Apple Silicon for the server, which no test on a pull request starts for real). It follows the order a contributor meets things in: 1. Open the app with no sites. **Create new site**, a Core site, in a folder with a space in its path. The setup checklist runs its steps; the terminal's button at the foot of the window shows what each is doing. 2. Let the checklist's last step start the server, and finish WordPress's own setup in the browser. Back in the app the header says "Server running" and "Build watching". Stop the server and start it again: from **Server running** in the header, or with **Stop** and **Start** beside "Server" in the details. 3. Press the three buttons at the left of the footer in turn. Terminal: type `help`. Logs: the server's lines, the build watch's, and Debug.log. Email: where SMTP is listening. Drag the tray's top edge. 4. Link a ticket by its number. The card shows the ticket and its pull requests and patches. 5. Apply one of them. The preview dialog names the files; **Apply and rebuild** runs the steps on the card. 6. Edit a file under `src/`, then **Review & submit changes**. The diff is the edit and nothing else. 7. Create a second site, or open one from before, and move between the two from the sites list. Each has its own terminal, logs and mail. 8. **Update to latest trunk** from the site's menu. **What must not have happened:** work lost in a link, an apply, a switch or an update that did not say so; `node_modules` rebuilt where nothing changed; a failure said only in a tray that stayed closed; one site's output in another's tray; anything on the page under the tray. **What cannot be tested by hand, and what was not:** none of the slices' manual steps were run by a person. I looked at screenshots and drove the app through the journeys; everything local was on macOS, with Windows left to CI. This pass is the first one by hand. ## Risks and limitations - **It is one commit on trunk**, since the repository allows only squash merges. The slices' pull requests are its record. `redesign/wpds` should not be branched from after this: it will have diverged from trunk. - **Reviewed in slices, not as a whole.** Twenty-two pull requests, all but a two-word change to `AGENTS.md` reviewed by a separate reviewer context before they were opened, most in two passes; see below. The branch was then swept once for what falls between slices, which found comments and one unread field (#617) and the three points that follow. - **Three questions and two failures still use the system's own dialogs**: the discards ask through its confirm box, and a path that could not be copied and a server started before there is a build are said in its alert. #557 meant to replace them and did so for deletions only. - **Some dialogs are repainted, not rebuilt.** The review dialog and its destinations, the mail dialog and the question an update asks about loose edits have the design system's colours and type on the old component library's parts. - **A real Gutenberg setup on Windows is not shown to pass on this branch.** See "How to test this". It passed on trunk before the redesign, in 35 minutes; here it was past 46 on its second attempt. Whether that is the runner or the branch is not known. - **The guide describes the old interface** until #561. Do not cut a release before it. - **The bundle roughly doubled** (#590): the sites list brings `DataViews` and what it needs. Launch time was not measured. - **Less is always in view.** A build's output, a new line in debug.log and a caught mail are in a tray that may be closed. A failure opens the terminal, or the logs if nothing else is open; unseen debug.log lines are counted on the footer; a mail that arrives shows nowhere until its tray is opened, which was decided and is not an oversight. - **Translation is about half done.** The shell, the cards, the tray and most dialogs go through the translator. Roughly 200 strings in components and hooks do not yet (the review dialog and its destinations, the setup checklist, the logs, most of what the hooks say), nor about 150 in the modules they take sentences from. Strings that are new are in English in the shipped translations until they are translated. - **Focus is lost in a few places**: when the app swaps what the tray holds from under it, when a notice with a focused button goes, when a row's own action removes the row. - **Some failures are still worded by the main process** ("Error invoking remote method…"): a failed rename, a failed setup. - **Things carried over, not made by this:** a start that throws leaves the server's button dead until a restart; erasing typed input in the terminal breaks once the line wraps; a line written to debug.log while it is being attached to can be shown twice. - **#571 and #603 will conflict with trunk after this**, in the mail's journey and helpers and in the dev server's hook. - Each slice's own list has more, and says which of its limits were chosen. ## Related Closes #557. Closes #558. Part of #542, which stays open for #559, #560 and #561. #555 and #556 are closed already. --- <details> <summary>Design decisions and alternatives considered</summary> - **An integration branch, and one landing.** A window drawn half by the old view and half by the new one could not be released, and the slices were too many to hold back one by one behind a flag. Fixes and changes with no visible effect went to trunk first and were merged across, so this diff is the redesign and little else. - **Landing before #559 to #561.** The plan was to land when all seven sub-issues were in the branch. The remaining three do not change what is there: two add to it and one documents it. Holding a finished window on a branch for them only lengthens the time trunk and the branch can drift apart. - **What the prototype lacks is kept and redrawn**, and what it has somewhere else moves to where it puts it. Its labels are adopted. Where a slice departs from it, the slice says so. </details> <details> <summary>Review outcome (required — see AGENTS.md)</summary> **No review of the whole diff was run. The record is the slices': twenty-two pull requests into `redesign/wpds`, each but one reviewed before it was opened by a separate, read-only reviewer context following `.github/instructions/code-review.instructions.md`, most in two passes (the change, then its fix-up), with the counts and the findings in each pull request's own review outcome. The one is #618, two words in a line of prose.** - **Review:** completed, per slice — #590, #594 to #602, #605, #606, #608 to #617 (no review was run for #618); everything marked to fix in a slice was fixed in that slice, and what was left is in its Risks. - **Review:** completed, for leftovers only — a separate agent context, read-only; `redesign/wpds` at `548c020` against trunk; not a review of correctness, which the slices had: a search for dead CSS and code, comments that waited for a slice that has landed, what is left of the old component library and of the system's dialogs, strings not yet translatable, and repository docs that name the branch. Nothing found in the stylesheet, the dependencies or the docs; thirteen comments and one unread field, fixed in #617; the rest is in Risks above. - **CodeRabbit:** not run. Its check reads "Review skipped: automatic reviews are disabled" on this pull request and on the slices, so the slices' pre-PR reviews are the reviews of record, each for the head it names. - **Since review:** nothing was added to the branch outside a reviewed slice, apart from three merges of trunk (`da19ac6`, `3344172`, `23d46e7`). </details> <details> <summary>Implementation notes</summary> - `git diff origin/trunk...origin/redesign/wpds`: 148 files, about 14,800 lines added and 3,000 removed; about 6,300 of the added lines are tests. - The site's view, which was one component of five thousand lines, is spread over the four regions the layout has: the header, the cards, the details and the tray. Decisions are in `src/renderer/*.cjs` with unit tests; components draw them. - New for the suite: journeys per region under `tests/e2e/journeys/`, lint rules of the repository's own (`eslint-rules/`), and Stylelint over the window's stylesheet. - The main process changed in one place for the redesign's sake: the debug.log tail says which lines the file already held (#614). </details> <details> <summary>Screenshots or recording</summary> Not attached: I have no way to upload images from the command line. The prototype shows the design; the signed build shows the app. </details> 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Item 9 of #557 is to replace every hardcoded colour with the design system's tokens, with as little hand-written CSS as possible. Parts 1 and 2 did the site page and its panels. What was left was inside the three dialogs still built on the older library: "Review & submit changes" with its diff and its three destinations, the "Update to latest trunk?" question, and the mail dialog. Between them they held 95 inline
styleattributes and 87 colour values, including a dark diff pane and a dark raw-mail pane that no longer matched the light terminal and logs.What changes
The three dialogs keep their frames, buttons and inputs from
@wordpress/components. Everything drawn by hand inside them is now the design system's.Notices: the old-trunk warning, the unreadable diff, nothing to send, someone else's work in the checkout, the branch based on today's trunk, the update question's failure, and test mode.Textin one of three shared classes,success-text,warning-textandproblem-text. These also replace the apply card's and the details sidebar's own copies, and.error-textfrom part 1 now uses the same red (its token gave a near-black#470000).shell.css.After this, no inline
styleand no colour value is left in any component undersrc/renderer.Deliberately not in this PR:
Dialog, or the review into the prototype's three-column drawer with a file list. That is a redesign of the screen, not colour work, and is not listed in Server section and process menus, ticket card, apply patch and others #557.window.confirm.How to test this
Platforms: any. The journeys below drive each dialog on macOS and Windows and assert the colours against the tokens, read from the window itself. From the repository root, after
npm ciandnpm run build:once:Each new assertion is red without the style it claims; I broke the rules one at a time to check (10 mutations, 10 red):
review-changes.spec.js: an added and a removed line are in the success and error colours on their washes; a failed save is in the error colour and a saved file's line in the success colour.trunk-update.spec.js: the chosen answer is ringed in the brand colour and the other is not, the ring moves with the choice, the chosen answer's detail is in the full text colour, and the answer that loses work stays red, chosen or not.mail.spec.js: the raw mail is on the weak surface.Worth a look by hand, since no journey judges taste (any platform, the current head):
What must not have happened: no wording, role or accessible name changed (the existing journeys find everything by role and text and pass unchanged, all 99), and nothing outside these dialogs moved except the two colour classes named above.
What cannot be tested by hand here: the GitHub device code and a real pull request result need a GitHub sign-in; the journeys stand in for GitHub and cover both states.
Risks and limitations
.error-text.Related
Part of #557, after #605 and #606.
Design decisions and alternatives considered
Noticewith nothing spoken. The design system's notice speaks its text when it mounts. Each one here either carriesrole="alert", as the box it replaces did, or was silent before and stays so; none is announced twice.Textrenders a span. Every one is a flex or grid item, or is given a block element, so no line runs into the next.Review outcome (required — see AGENTS.md)
Pass 1: 4 [fix here] · 2 [follow-up]. Pass 2 (on the fix-up): 2 [fix here], both low. 6 fixed, 2 accepted.
50129cd(rebased since, as369cf6e) / base9570450; compared each component with its old version, readNotice's implementation, computed contrast for every new pair; 4 [fix here], 2 [follow-up].tokenColourcould not notice a misspelled token (it now refuses one the window does not have);.error-textpainted the same error in a different red.86555dd/ base23d46e7; 2 [fix here], both low.86555dd → 1460d81adds that one assertion;trunk-update.specre-run, and red with the two rules swapped.Implementation notes
redesign/wpdsafter trunk's journey-engine fix (Fix a journey run failing on worker teardown after a launch that gave no window #607) was merged into it.ui.tokenColourandui.paintOfare new shared helpers intests/e2e/helpers/ui.cjs;logs.spec.jsandterminal.spec.jsuse the first in place of their own copies.npm testandnpm run test:electronpass (1863 tests),npm run test:e2e99 pass, the affected journeys pass in a 1024×728 window and with the status read slowed by a second,npm run test:e2e:packaged15 pass.Screenshots or recording
Not attached: I have no way to upload images from the command line. The three steps under "Worth a look by hand" show every changed surface, and Buildkite's build for this branch can be used for them.
🤖 Generated with Claude Code