yarn lockfile

[jordaaash]

Yarn is a package manager that I imagine you're already familiar with. It provides fast, deterministic dependency installation.

This commit is just a lockfile for the current dependencies of the SDK, obtained by running yarn install.

Having this allows anyone to build and use the library, resolve the correct dependencies, and benefit from yarn's package cache. It doesn't affect anyone who doesn't use yarn.

[coveralls]

Coverage remained the same at 94.408% when pulling 2795f50 on jordansexton:yarn into c6c9313 on Vincit:master.

[koskimas]

Isn't it better to just add yarn.lock to gitignore? Why does it need to be added to the repository?

[fl0w]

This is a bad idea IMO. This would require a new objection release for any dependency bump.

Better to let semver work its magic.

edit Huh, TIL!

[koskimas]

@fl0w Lock files of dependencies are ignored. This would only affect people who develop objection.

[jordaaash]

As far as I understand, the yarn lockfile needs to be checked in. This is just for building the library itself. This isn't a concern for application developers that don't build from the source; if they use yarn, they will generate their own lockfile, which they'll use in deployment.

However, if you're building the library from source, you aren't guaranteed to resolve the same dependencies as anyone else building the library from source.

[koskimas]

@jordansexton Maybe there is something I'm not getting. I'll read this article that seems to suggest that lock files should be committed even for libraries.

The thing that confuses me is this:
If the lock file is committed, everyone that builds objection gets the same dependencies. But what's the use of that? When people actually use objection they will get different dependencies (determined by their project's lock file). So I would think the lock file only causes bugs to be found in production instead of during development.

If there is a broken dependency, wouldn't the correct way to deal with it be to change package.json so that the library works again for everyone?

[koskimas]

The lock file would be a good idea for devDependencies, but not for real dependencies.

[jordaaash]

That article you linked has a good analysis of it, but the closing section of it suggests that developers building the library will only find issues users would find upon installing by reinstalling their dependencies anyway. This can always be done with yarn --force.

Additionally, if you are installing dependencies that have changed (let's say in the package.json, "some-dependency" is set to "^0.1.1" and the author has published 0.1.2), it's my understanding that yarn install will regenerate an updated lockfile.

This allows the change to be detected (where before it would have gone unnoticed) and the updated lockfile committed. You can use yarn --pure-lockfile (not the default) to only install dependencies from the lockfile. In practice, this actually makes breaking dependency changes easier to discover.

[jordaaash]

yarnpkg/yarn#570 (comment) has a more detailed explanation of the expected behavior of yarn when cloning the repo and setting up (TLDR section at the bottom).

[koskimas]

I can merge this, but who is going to keep this file up to date? I won't since I don't use yarn.

[jordaaash]

I'm happy to, but I would probably also get Greenkeeper.io set up to keep it up to date (and warn if any dependency updates break the tests) because I'm lazy 😜

[koskimas]

Greenkeeper can do that? I'll try to configure it. For some reason it has stopped updating the deps alltogether for objection. I'll need to look into it anyways.

[jordaaash]

Yep!

For each update to any of your dependencies, our bot immediately runs npm install and npm test.

I think it might also work just by having Greenkeeper open its PRs for dependency updates, since that should then trigger Travis to run, yeah?

[jordaaash]

Did some research, looks like you need to use this to get lockfile updates for free:
https://github.com/greenkeeperio/greenkeeper-lockfile

This looks cool as well, seems like a Greenkeeper alternative with built-in lockfile updates:
https://renovateapp.com