Storybook: Create centralized registry of component statuses#78472
Open
aduth wants to merge 2 commits into
Open
Storybook: Create centralized registry of component statuses#78472aduth wants to merge 2 commits into
aduth wants to merge 2 commits into
Conversation
|
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: 0 B Total Size: 7.98 MB ℹ️ View Unchanged
|
github-actions
Bot
added
[Package] Components
aduth
added
[Type] Task
|
Flaky tests detected in 10f3acf. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/26244302741
|
mirka
reviewed
May 21, 2026
Member
There was a problem hiding this comment.
I guess we should remove packages/components/storybook.d.ts now?
| const componentRef = meta.component as | ||
| | { displayName?: string; name?: string } | ||
| | undefined; | ||
| const componentName = componentRef?.displayName ?? componentRef?.name; |
Member
There was a problem hiding this comment.
Many components don't expose the registry key here, so the component status can get lost on components that previously had them. For example Slot, and wp-ui Tabs and Tooltip.
Member
Author
There was a problem hiding this comment.
Good catch. I don't really like how this code is trying to draw from conventions like path patterns and display names to figure out the package export. I noticed this earlier but I recall finding that's it's surprisingly complex to get some of the basic details about packages from this point in the code. I'll check it again though and see if we can find a different way to do this lookup.
Member
Author
There was a problem hiding this comment.
I updated this in 10f3acf to use useOf( 'story' ) instead of useOf( 'meta' ) which gives us a fileName path we can derive to a package with relative confidence. Extracting the component name from the Storybook title still feels a bit fragile, but there's nothing about Storybook that necessarily ties a Story to some export of a package, so this convention feels like the best we can do to attach it to the named export.
Member
Author
|
While it should be fine here, I think I'll need to revisit canonical component names in #78475. Many of our components are known to Storybook by their dot-deliminated names like |
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
2 participants
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.
What?
Updates implementation of component statuses in Storybook to use a centralized configuration, rather than detailing status in each individual component's Story.
Why?
This makes component status more readily accessible for a variety of use-cases.
Specifically, this is aimed at enabling:
@wordpress/design-system-mcp'manifest'tag for inclusion in the design system component manifest with an automated process using the centralized configurationComponent status isn't directly tied to Storybook, and while these updates don't yet detach it from the current Storybook usage (it still lives within the private
@wordpress/storybookpackage understorybook/), it does make it a smaller step to maintain this data elsewhere.How?
storybook/component-status.tswith a combined configuration of current component statuses@wordpress/storybook/component-statusexport (note: this is a private package, not published)componentStatusfrom individual storiesThis doesn't yet include the changes to add the component status to the components manifest or surfacing that information through the MCP server, which will be implemented separately (see #78475).
Testing Instructions
Verify there are no regressions in the display of component status after these changes:
npm run storybook:devScreenshots or screencast
Screenshot for reference, but this is unchanged from what already exists:
Use of AI Tools
Researched and implemented with Claude Code & Cursor + Claude Opus 4.7. Iterations based on manual review (e.g. removing
componentStatusoutright instead of replacing with utility function). Some code comments replaced with hand-written comments after manual review.