3 ms·

The reason why not to use lock files in libraries doesn’t make sense to me. Yes, you should ignore lock files in the .npmignore, so that they won’t be publish

The reason why not to use lock files in libraries doesn’t make sense to me. Yes, you should ignore lock files in the .npmignore, so that they won’t be published to npm, because library users don’t consume them. As a library author, where a lot of people are collaborating on a package, you will gain the same benefits: reproducibility and easier triage of bugs. If you are concerned about updates, you can utilize tools to automatically update your lock files (greenkeeper, dependabot, renovate). Renovate has a mode to completely update your lock file in a defined interval. Edit: your ci could also have a scheduled job which ignores the lock file (scheduled?), if you want to emulate a "integration" test and a "fresh" install

AgentME 7y ago
I agree. I have a bunch of little modules published on npm, and for all of them, I have a yarn.lock (or package-lock.json) lockfile committed in the git repo, but also listed in .npmignore so it's not part of the package published on npm. I do this so that all of the test/dev dependencies stay pinned to guaranteed working/tested versions, and so that there's a record of which versions of (non-dev) dependencies the library is known to work with. Here's a bunch of painful problems that happen when you don't check in your lockfile: * One of the most frustrating things in the world is checking out a git repo that's missing any lockfiles and then finding out that its build script or unit tests are broken with the current versions of the dependencies, so you're blocked on doing any work with the repo until you fix that. The extra frustrating thing is that people who previously checked out the repo (including the maintainer) won't run into this issue, so this issue will fall onto new contributors and be an obstacle to them specifically! * The next worst thing is getting a report from a user that your library no longer works with the current versions of its dependencies, and you don't even know which dependency is the problem or know of a good version of the dependency it worked with. Putting the lockfile in .gitignore opens you up to the two above issues, and then barely helps. Your CI system isn't going to re-run your tests when your dependencies or sub-dependencies get updates. You're going to have to set that up separately and then you could set that process up to ignore or update your lockfile so it's not a reason to git-ignore your lockfile.
- why-oh-why 7y ago
  > Your CI system isn't going to re-run your tests when your dependencies or sub-dependencies get updates. Yes and no. Your CI system runs when you want it to. If you want to check the latest dependencies, - with a lockfile you have to delete it, create a new one and commit it; - without a lock you just press the “rerun tests” on your CI
  - AgentME 7y ago
    Are you going to press the rerun tests button on every project every day in perpetuity? No one does that. If you're going to automate something to deal with this (that either reruns on dependency updates or just every day), then you can make that automation ignore or update your lockfile, and then the big problems in my post stay solved. If you run into a problem with a new version of a build/test dependency, then your project stays working for developers in the meantime until it's solved.
why-oh-why 7y ago
What’s the point of reproducibility in your team but not with your users (which is by definition the most common use case)? Libraries should skip lockfiles because they are ignored by the end user and therefore any testing you do based on them helps no one. I’ve had lockfiles being broken for no reason* so if you can avoid them, do. * For example, multiple versions of the same package were installed after several install/updates, but nuking the lock would avoid this issue and solve the problems it caused.
- viraptor 7y ago
  > any testing you do based on them helps no one. Counter example: they help PR authors. With a lockfile - CI fails which means the issue is most likely in the change. Without a lockfile - CI fails which means the issue is with the change, or the new dependencies, or the distribution of the new dependencies, or... Ideally testing new changes and updating deps are two completely separate processes.

AgentME 7y ago

I agree. I have a bunch of little modules published on npm, and for all of them, I have a yarn.lock (or package-lock.json) lockfile committed in the git repo, but also listed in .npmignore so it's not part of the package published on npm. I do this so that all of the test/dev dependencies stay pinned to guaranteed working/tested versions, and so that there's a record of which versions of (non-dev) dependencies the library is known to work with. Here's a bunch of painful problems that happen when you don't check in your lockfile: * One of the most frustrating things in the world is checking out a git repo that's missing any lockfiles and then finding out that its build script or unit tests are broken with the current versions of the dependencies, so you're blocked on doing any work with the repo until you fix that. The extra frustrating thing is that people who previously checked out the repo (including the maintainer) won't run into this issue, so this issue will fall onto new contributors and be an obstacle to them specifically! * The next worst thing is getting a report from a user that your library no longer works with the current versions of its dependencies, and you don't even know which dependency is the problem or know of a good version of the dependency it worked with. Putting the lockfile in .gitignore opens you up to the two above issues, and then barely helps. Your CI system isn't going to re-run your tests when your dependencies or sub-dependencies get updates. You're going to have to set that up separately and then you could set that process up to ignore or update your lockfile so it's not a reason to git-ignore your lockfile.

why-oh-why 7y ago
> Your CI system isn't going to re-run your tests when your dependencies or sub-dependencies get updates. Yes and no. Your CI system runs when you want it to. If you want to check the latest dependencies, - with a lockfile you have to delete it, create a new one and commit it; - without a lock you just press the “rerun tests” on your CI
- AgentME 7y ago
  Are you going to press the rerun tests button on every project every day in perpetuity? No one does that. If you're going to automate something to deal with this (that either reruns on dependency updates or just every day), then you can make that automation ignore or update your lockfile, and then the big problems in my post stay solved. If you run into a problem with a new version of a build/test dependency, then your project stays working for developers in the meantime until it's solved.

why-oh-why 7y ago

What’s the point of reproducibility in your team but not with your users (which is by definition the most common use case)? Libraries should skip lockfiles because they are ignored by the end user and therefore any testing you do based on them helps no one. I’ve had lockfiles being broken for no reason* so if you can avoid them, do. * For example, multiple versions of the same package were installed after several install/updates, but nuking the lock would avoid this issue and solve the problems it caused.

viraptor 7y ago
> any testing you do based on them helps no one. Counter example: they help PR authors. With a lockfile - CI fails which means the issue is most likely in the change. Without a lockfile - CI fails which means the issue is with the change, or the new dependencies, or the distribution of the new dependencies, or... Ideally testing new changes and updating deps are two completely separate processes.