use exact versions instead of version ranges

[nikhedonia]

Every now and then all our packages break because we have multiple versions of storybook in our dependencies. We have been tackling this issue by using yarn-resolutions but this is not a very maintainable approach.

The root of this issue is that dependencies of dependencies use version ranges making build irreproducible.

For instance installing [email protected] requires storybook@^3.3.13 which resolves to [email protected] (today 3.3.15) causing two different and incompatible versions of storybook to be present.

When ws upgraded from 3.3.3 to 3.3.4 all storybook versions broke due to "small" changes in error-handling.

Conclusion: storybook breaks everytime when a dependency of a dependency breaks making storybook builds non-reproducible.

Could we move to exact version numbers?

references:
newsuk/times-components#716
newsuk/times-components#673
newsuk/times-components#658
newsuk/times-components#650
newsuk/times-components#641
newsuk/times-components#629
facebook/react-native#6627
#2923
websockets/ws#1256

[danielduan]

We only test the same version of all @storybook packages together, so if you're using @storybook/[email protected], all your addons should all be 3.3.15.

With that said, I can see how these patch versions could potentially cause minor bugs.

@Hypnosphi @shilman thoughts?

I think with the help of dependencies.io, we could potentially pin versions and upgrade them. I don't see this preventing any bugs from being shipped since we don't actively test patch version upgrades manually.

[Hypnosphi]

I see why we should use exact versions for cross-dependencies between our own packages. For external ones, I still see a value in using ranges, because that allows package managers to optimize the size of your node_modules directory.

The situation with ws was an exception rather than a rule, usually people try hard not to break things in non-major releases

[danielduan]

@nikhedonia I suggest you guys upgrade with yarn upgrade-interactive instead of deleting the lock files.

As far as our workflow goes, I think this makes sense to me with the exception of react native. I think each minor 0.x release on react-native is a breaking change and we incorporate them as patch versions.

Opinions on how to address the upgrade cycle for RN?

[Hypnosphi]

with the exception of react native

I've actually disabled react-native updates in dependencies.io

[danielduan]

I'm gonna close this issue as there isn't anything else we will address.

[Hypnosphi]

I was actually going to do this part:

use exact versions for cross-dependencies between our own packages

[nikhedonia]

Thank you @Hypnosphi for your quick fix. This should solve 99% of the storybook related issues we used to have.

[Hypnosphi]

Released as 3.4.0-rc.2