Skip to content
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

Unnecessary peerDependencies #34

Open
dobesv opened this issue Jun 8, 2022 · 4 comments
Open

Unnecessary peerDependencies #34

dobesv opened this issue Jun 8, 2022 · 4 comments

Comments

@dobesv
Copy link

dobesv commented Jun 8, 2022

The core storybook plugins use regular dependencies but this package is using peerDependencies.

For example: https://github.com/storybookjs/storybook/blob/next/addons/actions/package.json

It seems like it would be nicer to follow their example as that makes the package easier to use without getting warnings about missing peer dependencies for packages that we aren't directly using ourselves.

@bryanjtc
Copy link

I agree

@bryanjtc
Copy link

@ghengeveld Do you have any reason for keeping them in peer dependencies?

@ghengeveld
Copy link
Member

The official/essential Storybook addons are all part of the Storybook monorepo, and are released in tandem with Storybook itself (they follow the same version number). The pseudo states addon is not part of the monorepo (perhaps it should be?) and therefore has its own (semver) versioning.

If we'd change the peerDeps to regular dependencies, we'd end up having to release a new version of the addon every time SB publishes a new version. Otherwise the addon would install one version of those SB packages, whilst your project may be using a different SB version. I'm not sure how every package manager deals with potentially deduping those packages when using semver ranges, but duplicate packages are a big source of bugs.

@dobesv
Copy link
Author

dobesv commented Aug 14, 2023

release a new version of the addon every time SB publishes a new version

I'm pretty sure it would work if you allow a range of storybook versions, as long as the ranges are overlapping between the dependent projects then npm and yarn should de-dupe them.

Your current approach technically also requires you to release new versions of the addon to support new versions of storybook, because package managers like yarn PnP won't share the peer dependency with other packages if the version range doesn't match OR if the way that the peer dependencies are satisfied for a package doesn't match.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants