Docgen: Only add react-docgen info when a component is defined in the file #26967
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.
This avoids errors when a component is being imported and re-exported under a different name via a barrel file or similar.
Closes #26074
What I did
The issue occurs when the react-docgen plugin is attempting to add the additional metadata into a file that exports the component, but doesn't contain the definition or a local with the same name.
I couldn't see enough information in the
react-docgen
handlers to distinguish between a re-export and a definition, so I've made the extra docgen handler already defined in this loader make a note of the filename from the component definition.When modifying the AST to add the docgen info, we only assign the info if the definition file is the same as the file we're transforming. This could potentially lead to other scenarios no longer adding the docgen info, but I believe that as long as the file containing the definition is still being processed by the loader, it should only be removing redundant re-assignments.
I'm not especially precious about taking this approach to resolve the issue, so please let me know if an alternative approach is preferred and I can give that a go instead.
Checklist for Contributors
Testing
The changes in this PR are covered in the following automated tests:
While I was able to to add a story to the sandbox which reproduced the issue, I struggled to see how this is executed as part of the testing/CI process, so I'd appreciate any pointers if there's something I've missed.
Manual testing
react-webpack-18-ts
renderers/react/js-argtypes
storyDocumentation
I don't believe any documentation is required.
MIGRATION.MD
Checklist for Maintainers
When this PR is ready for testing, make sure to add
ci:normal
,ci:merged
orci:daily
GH label to it to run a specific set of sandboxes. The particular set of sandboxes can be found incode/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>