Open shilman opened 1 year ago
I also have https://github.com/storybookjs/eslint-plugin-storybook/issues/74 open, which I think is the same as this. So I closed it out.
export const MyStory (…)
ExportNamedDeclaration
s: export { MyPreviouslyDefinedStory, AnotherOne }
MyPreviouslyDefinedStory
or AnotherOne
has no effectThat repro should be self-explanatory. What's your take on this ? Should it be supported or should we create another ESLint rule to warn users who use this pattern that specifying a name
property on re-exported declarations has no effect on the actual name being used by Storybook?
I personally do not see any obvious technical reason (performance or code convenience, maybe ?) which prevents us from supporting this, assuming any export ineluctably refers to an actual Story.
@shilman sorry to ping you, just leaving this question here until you find some time, but really nothing urgent :)
@Dschungelabenteuer If we support that export construct but it doesn't respect the name
annotation then that sounds like a bug to me.
Fair enough! I'll stick to the original issue for now and see what I can do, thanks!
Just for the record, here is another scenario I think I did not mention earlier.
Is your feature request related to a problem? Please describe.
When overriding a story name it must be a string literal. Not a variable and not a template literal.
https://discord.com/channels/486522875931656193/1054051640946208768/1055259413415481394
Describe the solution you'd like
Check for this and warn the user. Ideally provide fix.
Describe alternatives you've considered
Making CsfFile smarter. But since there will always be limitations to static analysis, we need some kind of linting regardless
Additional context Add any other context or screenshots about the feature request here.