What do you think of lockfiles?

[luftywiranda13]

Hello Sindre!

In the latest npm (version 5), it creates package-lock.json by default. Yes same like yarn for now.
What do you think of it? Should we commit the lockfile to git or is it better to get it ignored?

And also what do you think about the latest npm itself? Does it miss something?

Thanks, great day!

[dangh]

The purpose of lockfile is to lock the explicit package version and checksum, since package.json doesn't do that (like lodash: ^3.0), so when you run npm install on the production server or on other dev machine you get the identical packages. So no "It work on my side" execuse. Also helped to prevent infected packages, like when your internet connection has been interfere and redirect to a hacked server, etc.
Definitely should commit it.

[sholladay]

The lockfile defeats the whole purpose of the caret ^ that is the default save behavior. And it prevents us from getting security patches immediately, which is insane. There are more good updates than bad updates, so it does more harm than good. The idea that it protects us from malicious code is silly because there's no way in hell that people are actually auditing the entire dependency graph when they do finally get around to updating the lockfile. It's a fallacy that leads to a false sense of security.

[sonicdoe]

Just FYI, Sindre let me know on Twitter that he doesn’t intend to commit the package-lock.json:

Only if you commit package-lock.json, which I don't intend to do for packages.

[luftywiranda13]

@sonicdoe yeah that's the reason i ask him here. maybe he can explain a bit more here

[dangh]

@luftywiranda13 I think he don't intent to commit it for the packages, and I think it shouldn't be also. The package should be flexible and shouldn't lock the user from using newer packages it depends on.
That's the application's responsibility, not the lib's.

[luftywiranda13]

@dangh but i have a specific concern behind this as the reason why post him a question here, but let's just wait for Sindre to answer first then maybe we can discuss it 😄

[sindresorhus]

Lockfiles for apps, but not for packages. Lockfiles are great for apps where you want a controlled reproducible environment, but for packages this doesn't make much sense. The package-lock.json files in dependencies are ignored, so the lockfile only applies when users run npm install in the package repo. If you use a lockfile for packages, your local dependency tree will not match the dependency tree of users having your package as a dependency. This can potentially cause problems if one of your package dependencies breaks your package in a patch release. The lockfile will prevent you from seeing the problem locally, but it will affect your users. I also don't like the diff churn lockfiles create, so I only use them when they're actually beneficial.

[sindresorhus]

And also what do you think about the latest npm itself? Does it miss something?

It's a much needed rewrite with many nice features, but it's currently way too buggy for actual usage: npm/npm#16991 I'm staying on npm v4 for now.

[sindresorhus]

If you 👎 my comment, please tell me how I'm wrong (with technical arguments).

[oligot]

I just found this article on the yarn blog regarding lockfiles : they explain why (in their opinion) lockfiles should also be committed for libraries.

[RayBenefield]

I think adding a lockfile for any project is extremely valuable as it reduces the amount of unknowns when debugging issues. More knowledge is more valuable than less in my opinion. Theoretically if someone comes in with a breaking change after installing a package as a dependency you can have them locally install the package (having the lockfile manage the dependencies), symlink to the local with the expected dependencies, and check if the problem still exists. If so, then you've easily narrowed down what the problem could be.

Granted there may be a better way to detect if versions being out of sync are the problem, but I still contest that there is value to knowing what depedencies are expected than not. Especially since when a bug is found and debugging needs to happen, there is a number of reasons the package collaborators won't have the same versions of dependencies at the time the bug was caught compared to the time when they released the last version of the package that is potentially introducing the bug. With a lockfile you can at least look at the dependencies at the time that version was released (as opposed to whatever it is you have installed locally). The amount of unknowns grows rapidly with the amount of unique collaborators and their environments. Plus if you also switched development environments regularly (work vs home computer), it is possible (though probably rare) that one environment falls out of sync with another environment when you are not using lockfiles which could potentially introduce a hard to track down bug during package development.

More known data makes inevitable failure easier to track down and squash. That's my philosophy.

[benwiley4000]

@sindresorhus I found your argument very compelling, and was opening a pull request to one of the libraries I maintain to .gitignore our package-lock.json (as it seems others have done), and then I read the yarn blog post @oligot shared, which was also compelling, and I cancelled my pull request. I'd be curious what you think after giving it a read.

[mifi]

I'm wondering what you think about node.js CLI modules. Those can be considered "apps" because they are installed globally and are run from the command line (and not included in another node project which has its own lockfile.) I see that your CLI modules don't provide any pacage-lock.json or yarn.lock. So theoretically if any sub-dependency releases a buggy or exploited minor version it could break for example npm i -g np for everyone, am I thinking right?

[sindresorhus]

@mifi I don't think they're exactly like apps. You don't install apps with npm i -g. Also, npm ignores any package-lock.json in the package when installing it.