modify .yarnrc to force frozen-lockfile for yarn install

[alxiong]

As I keep git checkout yarn.lock, I realize maybe we should follow this issue

[snario]

Thoughts @joelalejandro @ebryn

[alxiong]

Yes, it also might be helpful to be explicit about what's the best practice for who (anyone? or only greenkeeper) & when (on every pull and yarn install or when adding new dep) to update the yarn.lock, or at least the standard inside the team

[ldct]

+1 - I don't understand how the current setup works, specifically why running yarn locally would update yarn.lock, and why CI uses --frozen-lockfile

[snario]

CI uses --frozen-lockfile because if, on the CI, the yarn.lock file was changed and thus the git working tree was modified, the step to deploy to Heroku will fail because deploying to Heroku implicitly does a git push which will error saying you need to handle your working tree changes.

[alxiong]

@snario so anyone pulling the repo and after yarn install on their local machine, realize there's update to yarn.lock, are they supposed to push that to the master branch through PR?
--frozen-lock should only be used for CI?

[snario]

I think that's a good convention.

Perhaps there should even be a CI check such that if yarn runs and changes then the PR should fail until a commit is added with the necessary change to yarn.lock?

[Alonski]

@snario I think the root cause of this problem is that greenkeeper doesn't update lock files. I have been using renovate lately and it does do that. Also free for open source. It can also automerge if tests pass.

[snario]

See #1261 which needs to be worked on.

We can remove Greenkeeper in that PR, too.