Update yarn.lock automatically

[SiAdcock]

Currently Greenkeeper doesn't support yarn. Perhaps it never will.

There is a workaround that would allow us to update the yarn.lock as part of the Travis build process. We could potentially update our deploy.sh to include this additional functionality.

This means we won't have to manually commit changes to yarn.lock when Greenkeeper, or anyone else, adds, removes or updates a node dependency.

[crgeary]

I don't think it ever will. I read a post from the guy that created it, and he was talking about using it for the speed & cache*, but not committing the lock file up. NPM actually has the ability to create lock files (although never used it).

. * Not sure where I read this, thought it was the above article, but must have been somewhere else.

[SiAdcock]

I've used npm-shrinkwrap before. Yarn claims to use a more deterministic algorithm to generate its lockfile ensuring that running npm install will always install the exact versions of each dependency and your dependencies' dependencies.

I do remember one strange day in the npm-shrinkwrap times. I had a build working locally, so I shipped the code, it built in CI and the site worked fine. One day, the build just stopped working. One of our dependencies had updated the version of one of its dependencies, which meant npm install installed slightly different modules without us having made any code changes, and despite us having an npm-shrinkwrap.json. This version change caused the build to fail and we couldn't ship anything for about 6 hours until we had worked it out. In my opinion, this should never happen. Yarn guarantees that it won't.

Perhaps we can close this as it's not really that big a deal anyway. I don't trust our build process enough to just merge Greenkeeper PRs without first testing locally anyway. If we're gonna test version updates locally, we can just commit and push the resulting lockfile at that stage.

I'll stop rambling now 😅