Blocks: Fix Stories block rendering duplicate stories when globals are changed

[JReinhold]

Closes #24751

What I did

This PR refactors DocsContext so it's more resilient in scenarios where multiple CSF files are being attached.

The cause of the linked issue was that rendering <Meta /> would call attachCSFFile, and changing a global causes the whole docs view to re-render. This meant that attachCSFFile would be called again with the same CSF file, which would just append the stories to the existing array in DocsContext again and again.

Upon investigating this I concluded that DocsContext wasn't completely implemented in a way that handled multiple CSF files being attached at the same time. This could theoretically result in the primaryStory being the primary of the first attached CSF file, however a resolved meta or component would return the one from the last attached CSF file. This has now been fixed in this PR - the first attached CSF file will always be considered the "primary" one to resolve from.

However I haven't figured out how to test this in practice, I can't set up a scenario where multiple different CSF files are being attached to the same context. Based on the comment here, it suggest that this is a valid scenario though in non-manual-MDX files:

storybook/code/lib/preview-api/src/modules/preview-web/render/CsfDocsRender.ts

Lines 106 to 108 in 332c593

	// All referenced CSF files should be attached for CSF docs
	// - When you create two CSF files that both reference the same title, they are combined into
	// a single CSF docs entry with a `storiesImport` defined.

I tried having two different CSF files with the same title, and while that did collect all stories under the same component in the sidebar, it didn't make a difference in autodocs. @tmeasday any ideas on how I can test this out in a real Storybook?

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

1. Open these docs, which is an MDX doc with <Stories />: https://630511d655df72125520f051-tprruuakio.chromatic.com/?path=/docs/addons-docs-docs2-button--metaof
2. Toggle any of the globals multiple times and see that the amount of stories stay the same.
3. Compare that with what's on next, where it duplicates the stories when globals are changed: https://next--630511d655df72125520f051.chromatic.com/?path=/docs/addons-docs-docs2-button--metaof

Documentation

• Add or update documentation reflecting your changes
• If you are deprecating/removing a feature, make sure to update
  MIGRATION.MD

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/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>

[JReinhold]

This is the actual fix for the issue, if we actually don't think supporting multiple attached CSF file is a valid use case then this PR can be reduced to these lines.

[tmeasday]

I tried having two different CSF files with the same title, and while that did collect all stories under the same component in the sidebar, it didn't make a difference in autodocs. @tmeasday any ideas on how I can test this out in a real Storybook?

Did the index end up with the storiesImport on the autodocs entry containing a second CSF @JReinhold ?

According to this test it should:

storybook/code/lib/core-server/src/utils/StoryIndexGenerator.test.ts

Line 686 in 82504d6

it('generates a combined entry if there are two stories files for the same title', async () => {

In which case I would have expected the line referenced by that comment to run, which would attach the second CSF file's stories to the docs context, and they'd show up in autodocs. I guess that's not happening, I would have to debug through why. Maybe we can do it together?

[tmeasday]

I think the changes look good apart from one nit.

I think maybe we should try and add some sandbox stories for this situation and maybe an E2E test that checks the behaviour?

[JReinhold]

@tmeasday I don't know what happened, but when adding the E2E tests it works as expected, stories from multiple CSF files are merged in autodocs. I must have gotten my test-setup wrong.

It doesn't work in MDX but that's to be expected.