-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add CJS output of preview entry #67
Conversation
"@storybook/preview-api": "8.0.0-beta.2", | ||
"@storybook/react": "8.0.0-beta.2", | ||
"@storybook/react-vite": "8.0.0-beta.2", | ||
"@storybook/addon-essentials": "8.0.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldn't the deps be ^8.0.0 instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is actually on purpose, originally discussed here #59
tl;dr by pinning to 8.0.0 (similar to what we did for 7.0.0) we're encouraging addon authors to support the whole major version range instead of just the latest minor release. If they specifically need an API from a later minor, they can upgrade to that intentionally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it! But doesn't that mean they won't notice issues in CI or locally? If 8.1.0 releases something that ends up affecting the addon (which we know can happen), then they won't know. This would make more sense if we set up a nightly CI check that uses npx storybook@latest upgrade and then runs yarn build and optionally yarn test-storybook
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see what you mean, it would be ideal to support "both", I don't feel like adding that CI workflow now, since I don't think it's that simple to test an addon, given they are often manager functionality which can't be represented in a story.
I'd rather optimize for addons to support a whole major range, than I'd optimize for addons to catch bugs/regression we introduce in a Storybook minor release.
Add CJS preview entry, to be used by Jest when using Portable Stories