Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What do you think of lockfiles? #479

Closed
luftywiranda13 opened this issue Jun 14, 2017 · 21 comments
Closed

What do you think of lockfiles? #479

luftywiranda13 opened this issue Jun 14, 2017 · 21 comments

Comments

@luftywiranda13
Copy link

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
Copy link

dangh commented Jun 16, 2017

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
Copy link

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
Copy link

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
Copy link
Author

luftywiranda13 commented Jun 21, 2017

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

@dangh
Copy link

dangh commented Jun 21, 2017

@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
Copy link
Author

@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
Copy link
Owner

sindresorhus commented Jun 23, 2017

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 sindresorhus changed the title What do you think of lockfile(s)? What do you think of lockfiles? Jun 23, 2017
@sindresorhus
Copy link
Owner

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
Copy link
Owner

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

jaydenseric added a commit to jaydenseric/apollo-upload-client that referenced this issue Jun 25, 2017
Lockfiles are good for apps, not packages. See
sindresorhus/ama#479 (comment).
jaydenseric added a commit to jaydenseric/graphql-upload that referenced this issue Jun 25, 2017
Lockfiles are good for apps, not packages. See
sindresorhus/ama#479 (comment).
@oligot
Copy link

oligot commented Jun 26, 2017

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
Copy link

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.

Vestride added a commit to Vestride/Shuffle that referenced this issue Jun 30, 2017
benwiley4000 added a commit to jpeg-js/jpeg-js that referenced this issue Jul 16, 2017
@benwiley4000
Copy link

benwiley4000 commented Jul 16, 2017

@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.

luftywiranda13 added a commit to luftywiranda13/generator-bunny that referenced this issue Aug 5, 2017
Lockfiles for apps, but not for packages.
sindresorhus/ama#479 (comment)
luftywiranda13 added a commit to luftywiranda13/generator-bunny that referenced this issue Aug 5, 2017
Lockfiles for apps, but not for packages.
sindresorhus/ama#479 (comment)
jestcrows added a commit to jestcrows/ethtaint that referenced this issue Aug 5, 2017
krasivyy3954 added a commit to krasivyy3954/react-graphql-upload that referenced this issue Jan 6, 2023
Lockfiles are good for apps, not packages. See
sindresorhus/ama#479 (comment).
mohammadxali added a commit to prezly/theme-kit-js that referenced this issue May 18, 2023
mohammadxali added a commit to hidevs/l5-client-js that referenced this issue Jan 5, 2024
mohammadxali added a commit to hidevs/l5-client-js that referenced this issue Jan 5, 2024
@airtonix
Copy link

airtonix commented Jun 21, 2024

@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.

@sindresorhus Is this still your opinion in 2024?

Because there's two stories here (for one of them your point of view makes sense):

  1. people that consume the library.
  2. people that contribute to the library.

Consumers

Now lets first acknowledge that in story 1, the lockfile gets ignored by the consuming tools anyway.

How the consumers package manager behaves is driven by dependencies, peerDependencies, optionalDependencies`.

Contributers

This is you, your team mates and anyone that stops by to help out.

How will you ensure that time is not wasted on problems easily circumvented by simply pinning the hash of all your packages.

@sindresorhus
Copy link
Owner

How will you ensure that time is not wasted on problems easily circumvented by simply pinning the hash of all your packages.

I would rather know about issues with dependencies that users are having, even if it adds a slight burden on a contributors. As always, it's about trade-offs. I have gone without lockfiles for years, and contributors to my projects rarely have any issues. There have been a few cases of a lining rule changing behavior, but that was an easy fix. What has broken my project many times was changes in Node.js versions and the OS, or differences in the OS setup, which lockfiles would not help with. Lockfiles could actually cause the opposite problem here. A new Node.js version breaks something, a dependency gets fixed in a patch version, and contributors still experience the issue because the lockfile prevents using the new patch version of the dependency. It may be possible to pin Node.js version used in a project too, but you still cannot pin the operating system.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests