-
Notifications
You must be signed in to change notification settings - Fork 2k
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
[WIP] Build: remove npm-shrinkwrap.json and try yarn #8660
Conversation
Test live: https://calypso.live/?branch=try/yarn |
RUN npm install --production || npm install --production | ||
COPY ./yarn.lock /calypso/yarn.lock | ||
|
||
RUN curl -o- -L https://yarnpkg.com/install.sh | bash && export PATH="$HOME/.yarn/bin:$PATH" && yarn install |
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 better to wait until @dmsnell's docker changes are in before debugging this too far
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.
You can just install it using npm install yarn --global
. Somehow I find the curl | bash
installation method too magic :)
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.
How about npm install yarn=0.15.1 -g --prefix ./node_utils
and then run with ./node_utils/bin/yarn
?
This way we can control the version we are using and not clutter global.
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.
whoa! where's that global flag coming from - stop messing up my system! 😄
@gwwar in relation to the Dockerfile we may have more issues with the deployment process than code conflicts because it specifically sets a local npm mirror.
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 mostly meant that we should wait since our base image is changing from Debian to node-slim with @dmsnell upcoming changes. If you look at https://yarnpkg.com/en/docs/install#linux they also provide the package via apt-get, but I was running into trouble configuring the apt-get repository to be able to download yarn.
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.
Note to self, this should also be run with yarn install --production
to skip over devDependencies. https://yarnpkg.com/en/docs/cli/install
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 install --production to skip over devDependencies
probably not @gwwar because the Docker container builds the bundles from source. we may not need linting but we certainly need the loaders and babel etc…
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.
If we use something in both prod/dev, that makes it a plain dependency 😄 If you look at our package.json, babel should be under dependencies
vs devDependencies
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'm waiting until #8603 lands before making additional changes in the docker file. Though feel free to experiment 😄
@@ -80,7 +81,10 @@ welcome: | |||
@printf "\033[36m |___/|_| \n" | |||
@printf "\033[m\n" | |||
|
|||
install: node_modules | |||
yarn_available: |
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 seems like an odd name for a make target. it's almost as if it should return some boolean indication, but it's really just forcing a dependency. maybe something like demand_yarn
or yarn_check
would fit better
@gwwar why do we need yarn installed globally? is it possible to use a local copy and |
expect( payment.type ).to.equal( 'credit_card' ); | ||
expect( payment.countryCode ).to.equal( 'US' ); | ||
expect( payment.countryName ).to.equal( 'United States' ); | ||
expect( payment.name ).to.equal( 'My VISA' ); |
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 a win outside of this PR too, no? could we move these changes into a quick-fix PR and just push it out there? it doesn't really seem to fit well with the yarn
stuff
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.
added in #8698
@@ -1,6 +1,11 @@ | |||
machine: | |||
node: | |||
version: 6.7.0 | |||
dependencies: | |||
pre: | |||
- curl -o- -L https://yarnpkg.com/install.sh | bash |
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.
versioning much? I think we could pull from https://github.com/yarnpkg/yarn/releases if we wanted to pin it and make updates their own PRs
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.
Hmm interesting thought for fixing yarn versions. Should we maybe try to bump to latest on each node bump?
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.
Seems good to me. Having it versioned makes for nice explicit changes in PRs
I can give that a shot. Was doing some quick hacks yesterday ;D Edit: note that we'll see this annoying prompt |
8445722
to
09d7577
Compare
yuck. it's probably okay if we need to. I see the causal dependence on npm that could make this tricky and justify a global. globals can be just so nasty |
I said this above but got no response, what about:
We can then |
sorry if I missed your comment @umurkontaci but that sounds like a great idea now, let's pause and consider our other globals. how many (if any) do we depend on? could this same solution make all of them non-global? |
No worries! 👍 Also double checked that it does not link to any folder in
Apart from shonkwrap, I don't think we have any.
After |
Just FYI It's poorly documented at the moment, but @blowery mentioned in the hangout that yarn stores a cache at @umurkontaci I think that approach looks good, but we'll want to check where it's placing the cache directory |
Good catch. Per https://github.com/yarnpkg/yarn/blob/master/bin/yarn.js#L11 it will use the home directory of the user regardless. Home directory is We can probably fix this in the upstream by adding an option to set the cache file name from an env value or an optional command. |
Thanks for 👀 @umurkontaci. That seems like a good step to take. We can probably steal a few ideas from yarnpkg/yarn#749 as well |
@gwwar any reason this is on hold? are we waiting for more stabilization in yarn? I think we can 🚢 it with |
I'm waiting for yarn to stabilize a bit more. There are open issues like yarnpkg/yarn#761 that I'd not like to debug in prod |
An in progress branch to see if we can use yarn and ditch npm-shrinkwrap.json