Why don't we include yarn.lock?

[zirho]

Is there any reason for that?

[larixer]

@zirho The only reason for this is that people might not use yarn and just plain old npm and wouldn't need this yarn.lock file. But maybe this doesn't make much sense.

[zirho]

I see. I think including the yarn.lock makes sense when you advise to use yarn in installation instructions.
You would not want to mention yarn at all if you don't want this file in your repo because they will see yarn.lock change, every time they do yarn command.

I guess adding it to .gitignore is not an option, since it will differ dependency versions in deploying process. Please consider including it. 👍

[larixer]

@zirho I don't like the idea of including generated files of various tools into source code. yarn.lock is a big generated file of yarn tool. Yes, we support yarn and npm, we support IntelliJ, Eclipse, vi and Atom in the same sense, but we are not going to include the generated files of these tools.

[zirho]

I have a different opinion on that, but it would be more like preference.

Look at these most popular Open-source projects.
https://github.com/facebook/react
https://github.com/reactjs/redux
I'm not telling you that you should include that because those two include all kinds of configs or preference files in their repo.

My reasoning is this.
Open-source projects are made for anyone who use all kinds of different editors, IDEs or platforms.
To mitigate the pain to setup a development environment on every different setups, those file are needed.

If you decided to support yarn package manager, yarn.lock is mandatory.

So if you insist not to include yarn.lock, you would want to drop the yarn instruction in README.md because anyone who makes a PR with yarn installed setup, will probably include yarn.lock in their commits.

[langpavel]

yarn.lock is not needed for yarn. This file only guarantee package versions in production. I'm sure it have it's role in development too.
When some package breaks it's semver versioning, all dependants are affected. yarn.lock is one protection against this more rarely situations over time. Just for clarification.

Including yarn lockfile is recommended by yarn for good reason. You can at every time check if you are using different deps and if you fall back to ones where everything works, you can blame yourself cleanly..

[larixer]

@langpavel Thanks for clarifications Pavel. Do you think it is a good decision to include yarn.lock into starter kit, will it have visible benefit?

[larixer]

@zirho Lets try it. I will try to include yarn.lock over weekend, I suspect that it might affect Travis and Heroku setup, so I will need time to check that they work as before. After that we will see how it feels to have yarn.lock in the repo and what are the pros and cons of this approach

[larixer]

@zirho @langpavel Okay, I took first look at including yarn.lock and the problem is including yarn.lock will break Travis builds of Greenkeeper for this repo. Please see this issue:
greenkeeperio/greenkeeper#314
We need to wait until that issue will be resolved.

Working Greenkeeper is more important than yarn.lock, because yarn.lock tries to freeze package versions to prevent semver versioning breakage, whereas Greenkeeper actually REVEALS if this breakage happens in any package we are using and immediately reports this to us.