Open dobesv opened 2 years ago
I agree
@ghengeveld Do you have any reason for keeping them in peer dependencies?
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.
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.
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.