Manager: Add tags property to GroupEntry objects

[Sidnioulz]

What I did

I edited the code converting the story index to story hashes for use in the manager (transformStoryIndexToStoriesHash), to add a tags property for 'group' entries, which is the intersection of all their stories' hashes.

This is the 'group' counterpart of #29343. I am opening the PR because users of my addon have come to me requesting support for badges in group entries of the sidebar, which requires that tags are also computed for these: Sidnioulz/storybook-addon-tag-badges#20.

Checklist for Contributors

Testing

The changes in this PR are covered in the following automated tests:

• stories
• unit tests
• integration tests
• end-to-end tests

Manual testing

Add a tag 'new' to a component:

export default {
  component: MyComponent,
  tags: ['new'],
}

Add https://github.com/Sidnioulz/storybook-addon-tag-badges and verify that the tag shows up in the sidebar at the component level.

Add the tag deprecated to one of the stories, and verify that it shows up at the story level. Add the tag deprecated to all of the stories in the component and verify that it shows up at the component level in the sidebar.

OR

• Add a sidebar renderLabel function that prints all tags
• Notice the presence of 'dev', 'vitest', etc. tags in group entries in the storybook:ui instance

Documentation

Still not sure how/where to document this, like I pointed out in the component PR.

Checklist for Maintainers

• When this PR is ready for testing, make sure to add ci:normal, ci:merged or ci:daily GH label to it to run a specific set of sandboxes. The particular set of sandboxes can be found in code/lib/cli-storybook/src/sandbox-templates.ts

• Make sure this PR contains one of the labels below:

  Available labels

  • bug: Internal changes that fixes incorrect behavior.
  • maintenance: User-facing maintenance tasks.
  • dependencies: Upgrading (sometimes downgrading) dependencies.
  • build: Internal-facing build tooling & test updates. Will not show up in release changelog.
  • cleanup: Minor cleanup style change. Will not show up in release changelog.
  • documentation: Documentation only changes. Will not show up in release changelog.
  • feature request: Introducing a new feature.
  • BREAKING CHANGE: Changes that break compatibility in some way with current major version.
  • other: Changes that don't fit in the above categories.

🦋 Canary release

This PR does not have a canary release associated. You can request a canary release of this pull request by mentioning the @storybookjs/core team here.

core team members can create a canary release here or locally with gh workflow run --repo storybookjs/storybook canary-release-pr.yml --field pr=<PR_NUMBER>

name	before	after	diff	z	%
createSize	0 B	0 B	0 B	-	-
generateSize	77.7 MB	77.7 MB	0 B	-1.22	0%
initSize	143 MB	143 MB	574 B	-1.22	0%
diffSize	65.2 MB	65.2 MB	574 B	1.19	0%
buildSize	6.83 MB	6.83 MB	204 B	1.19	0%
buildSbAddonsSize	1.51 MB	1.51 MB	0 B	1.54	0%
buildSbCommonSize	195 kB	195 kB	0 B	-	0%
buildSbManagerSize	1.86 MB	1.86 MB	204 B	0.95	0%
buildSbPreviewSize	271 kB	271 kB	0 B	1.32	0%
buildStaticSize	0 B	0 B	0 B	-	-
buildPrebuildSize	3.84 MB	3.84 MB	204 B	1.19	0%
buildPreviewSize	3 MB	3 MB	0 B	0.73	0%
testBuildSize	0 B	0 B	0 B	-	-
testBuildSbAddonsSize	0 B	0 B	0 B	-	-
testBuildSbCommonSize	0 B	0 B	0 B	-	-
testBuildSbManagerSize	0 B	0 B	0 B	-	-
testBuildSbPreviewSize	0 B	0 B	0 B	-	-
testBuildStaticSize	0 B	0 B	0 B	-	-
testBuildPrebuildSize	0 B	0 B	0 B	-	-
testBuildPreviewSize	0 B	0 B	0 B	-	-

name	before	after	diff	z	%
createTime	7.2s	7.2s	-27ms	-1.02	-0.4%
generateTime	21.8s	19.9s	-1s -932ms	-0.34	-9.7%
initTime	15.7s	15.1s	-638ms	-0.08	-4.2%
buildTime	8.1s	8s	-79ms	-0.72	-1%
testBuildTime	0ms	0ms	0ms	-	-
devPreviewResponsive	5.5s	6s	519ms	0.09	8.5%
devManagerResponsive	3.6s	3.7s	113ms	0.07	3%
devManagerHeaderVisible	518ms	567ms	49ms	-0.32	8.6%
devManagerIndexVisible	547ms	632ms	85ms	-0.31	13.4%
devStoryVisibleUncached	908ms	1s	136ms	-0.08	13%
devStoryVisible	547ms	630ms	83ms	-0.27	13.2%
devAutodocsVisible	452ms	520ms	68ms	-0.15	13.1%
devMDXVisible	471ms	502ms	31ms	-0.4	6.2%
buildManagerHeaderVisible	509ms	626ms	117ms	-0.02	18.7%
buildManagerIndexVisible	519ms	640ms	121ms	-0.06	18.9%
buildStoryVisible	504ms	625ms	121ms	-0.02	19.4%
buildAutodocsVisible	393ms	454ms	61ms	-0.41	13.4%
buildMDXVisible	407ms	537ms	130ms	0.11	24.2%

Greptile Summary

Added support for tags in GroupEntry objects within the Storybook manager's sidebar, computing them as the intersection of child stories' tags.

• Added tags property to API_GroupEntry interface in code/core/src/types/modules/api-stories.ts
• Enhanced intersect utility in code/core/src/manager-api/lib/intersect.ts with stricter array validation
• Modified transformStoryIndexToStoriesHash in code/core/src/manager-api/lib/stories.ts to compute group entry tags
• Added unit tests in code/core/src/manager-api/tests/stories.test.ts verifying tag inheritance for group entries

[greptile-apps]

_{4 file(s) reviewed, 2 comment(s)
Edit PR Review Bot Settings | Greptile}

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit 8496e3e. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this CI Pipeline Execution

---

✅ Successfully ran 1 target

• nx run-many -t build --parallel=3

---

Sent with 💌 from NxCloud.

[shilman]

WDYT about updating API_BaseEntry and propagating tags all the way up to the roots?

[Sidnioulz]

It would make the TS API a bit cleaner indeed. But I doubt it would make sense as there's virtually no way the intersection of all stories' tags makes sense to compute. It would likely be a waste of CPU resources to compute.

[shilman]

As far as I understand here, you are propagating N-2 levels up the tree. The roots add a single extra level, which means one extra intersection per root, which means almost no extra computation compared to this change. For the benefit of a cleaner, more consistent API.

[Sidnioulz]

You're right that it doesn't cost that much and would simplify API for all users. Let me give it a go and see where it takes me!

I wonder if it would make sense to just document it as an empty array for 'root' entries, as that's what we expect would happen?

[Sidnioulz]

I also realise that I do indeed go down N-2, which was not intended. I wanted tag intersections computed as an intersection of direct children for obvious performance reasons.

I'll rework the code to do all tag intersection in a separate pass, starting from leaves and going back up the tree.

[Sidnioulz]

I ended up having to edit a few tests, because many test mock entries did not have tags defined in their input. This was a good opportunity to realise that tags, whilst mandatory on story entries, were never initialised and assumed to exist. I added an initialisation to an empty array when creating hash stories, prior to destructuring the index story item, to ensure types will remain valid in the future. Happy to remove that if you find it unnecessary.