-
-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
Make dependencies more deterministic #1703
Conversation
Codecov Report
@@ Coverage Diff @@
## release/3.3 #1703 +/- ##
============================================
Coverage 23.12% 23.12%
============================================
Files 253 253
Lines 5756 5756
Branches 677 674 -3
============================================
Hits 1331 1331
- Misses 3943 3946 +3
+ Partials 482 479 -3
Continue to review full report at Codecov.
|
CONTRIBUTING.md
Outdated
@@ -4,6 +4,8 @@ Thanks for your interest in improving Storybook! We are a community-driven proje | |||
|
|||
Please review this document to help to streamline the process and save everyone's precious time. | |||
|
|||
This guide assumes you're using `yarn` as package manager. You can use `npm` as well, but it would be less deterministic, as we only commit `yarn.lock` to the repo. |
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.
We should be impartial and publish a package-lock.json
as well imo. There's been problems with npm
respecting their own lock files but that's been fixed in [email protected]
.
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 will require running bootstrap two times (using yarn and npm) each time we add or change a dependency
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.
Personally I'm fed up with NPM and would like to just encourage yarn across the board for developing this project. Better platform and much easier than supporting both. Of course end users are welcome to use whatever they want. Thoughts?
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 definitely see the concern here and I think yarn is 100% the better package installer. Keeping backward compatibility with npm
is the worst. If we're gonna proceed with yarn
for the package installer of choice, we should make that very clear and keep to it.
When we phrase it, maybe it should say You should use 'yarn' as your package manager when developing 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 don't think that we should push this hard. If you use npm
after this change your experience will be the same as it is now for everybody =) But if you use yarn
, it'll be better
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 think the only time someone will actually use the raw npm
or yarn
command is when doing npm link
to link to an external project and npm install --save
to add a new dependency. In the new dependency case, we should definitely use yarn
since that will actually update the lock file.
I think for simplicity sake, we should just tell contributors to use yarn
. I would love to support npm
but the unnecessary complexity is really not worth it.
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.
npm install --save
You can't do that with lerna
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.
since that will actually update the lock file.
It will be updated after bootstrapping, which should be done anyway
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.
By the way, workspaces feature just became not experimental: yarnpkg/yarn#4262
If we use it, there will be more sense in stating that we have a yarn-only setup. I'd prefer to introduce it in a separate PR, but I can adjust the wording here if we decide to go that way
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.
We develop storybook using yarn.
If someone wants to install the root with npm, that's of no consequence..
The bootstrap script will use yarn.
We'll assume everyone uses yarn to develop storybook in our documentation.
"react": "16.0.0-alpha.12", | ||
"react-native": "^0.46.1" | ||
"react-native": "0.46.1" |
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 really don't see the benefit of locking our example apps. If a new minor version is released that breaks something, we really have no way of knowing. I know a few of us run these example apps to test if anything breaks before merging or publishing.
I think it's totally valid if we have separate example apps with version numbers locked for different version of react to test though.
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.
Sounds like quite a separate issue. It's good to check that things keep being compatible with latest version, but this check should run on master
not on PRs. Because if a new react-native
release breaks things, it's master
what should be fixed
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 understand your reasoning @Hypnosphi.
Generally I'd rather have errors all over the place when we're not compatible with latest.
This will keep us alert and nudges us to resolve it quickly.
It's annoying for PR's but PR branches can always lock it down if the problem comes up.
Having said that, I think in the case of ReactNative we want to be extra cautious. Reactnative itself is on the 0.x.y versioning and is actually using pre-released version of other packages. Locking them down sounds sane.
I'm really interested in what @shilman @tmeasday think about this.
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.
Definitely on the side of keeping up with latest. It will cause some headaches occasionally, but overall I think it will help us much more than it will hurt us.
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.
@ndelangen @shilman isn’t it a task for greenkeeper or similar tool?
# Conflicts: # CONTRIBUTING.md # examples/crna-kitchen-sink/package.json # examples/test-cra/package.json
# Conflicts: # CONTRIBUTING.md
CONTRIBUTING.md
Outdated
git clone https://github.com/storybooks/storybook.git | ||
cd storybook | ||
yarn install | ||
yarn run bootstrap -- --core |
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 should probably be updated to yarn run bootstrap:core
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.
Probably in another PR? Upstream branch has npm run bootstrap -- --core
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.
By the way, it's only by fortune that those are the same things in case of core
.
For example, yarn run bootstrap -- --react-native-vanilla
is not the same as yarn run bootstrap:react-native-vanilla
. Looks like only the bootstrap
command should be called immediately. @ndelangen, please correct me if I'm wrong
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.
@danielduan The way it is, is fine. We want people to use the bootstrap script. It's superior to remembering a list of npm script and that way we can change how we order our npm script.
CONTRIBUTING.md
Outdated
|
||
cd <your-project> | ||
npm link @storybook/react | ||
```shcd app/react |
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 looks broken to me?
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.
Yeah, looks like a merge artifact
CONTRIBUTING.md
Outdated
@@ -136,7 +134,7 @@ This project written in ES2016+ syntax so, we need to transpile it before use. | |||
So run the following command: | |||
|
|||
```sh | |||
npm run dev | |||
yarn run dev |
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.
yarn dev
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.
Ok, I just wrote verbose versions of commands so that it's easilly mapped to npm. If we go all the way yarn, I'll use shorthands
CONTRIBUTING.md
Outdated
``` | ||
|
||
### Getting Changes | ||
|
||
After you've done any change, you need to run the `npm run storybook` command every time to see those changes. | ||
After you've done any change, you need to run the `yarn run storybook` command every time to see those changes. |
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.
yarn storybook
I switched all the scripts in CI to use |
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 have tested
- the bootstrapping process
- the cra-kitchen-sink
- the vue-kitchen-sink
- the react-native-vanilla example
"react": "16.0.0-alpha.12", | ||
"react-native": "^0.46.1" | ||
"react-native": "0.46.1" |
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 understand your reasoning @Hypnosphi.
Generally I'd rather have errors all over the place when we're not compatible with latest.
This will keep us alert and nudges us to resolve it quickly.
It's annoying for PR's but PR branches can always lock it down if the problem comes up.
Having said that, I think in the case of ReactNative we want to be extra cautious. Reactnative itself is on the 0.x.y versioning and is actually using pre-released version of other packages. Locking them down sounds sane.
I'm really interested in what @shilman @tmeasday think about this.
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.
Any reason why this is not being merged into master instead of 3.3?
Seems like this is mostly contributor and documentation oriented changes.
Doesn't Apart from that I am keen on this change. |
@tmeasday why do you think it's so? |
@Hypnosphi I believe they need to run Luckily |
Looks like we don't have those |
Right but npm5 has |
Ok, looks like non-hoistable dependencies rest uncovered by this change. I don't think it's a stopper |
Agreed, although if you can figure out a solution it'd be great ;) |
We can try yarn workspaces for bootstrapping =) |
@Hypnosphi have not had success with yarn workspaces yet (it hoisted so aggressively that it caused problems in my project like lack of .bin directories in my sub-projects) but if you can get something working well i'd definitely love to see it and migrate eventually (if it works well and everybody else is on board) |
I’d wait for upcoming 1.0 release first |
Yeah, I think when workspaces does what we need, combined with @ndelangen's hoisting script, I think we'll be good. For now, this is a big improvement, right? |
.gitignore
ingyarn.lock
snpm
yarn
in first place