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

Do not pretty-print package-lock.json to prevent corrupting git lines count history #186

Open
wants to merge 1 commit into
base: release-next
from

Conversation

Projects
None yet
4 participants
@bl00mber
Copy link

bl00mber commented Apr 5, 2019

Because package-lock.json is not a human readable file, there is no need to pretty-print it.
Since this file created automatically and required by guidelines to include into git history it is severely corrupting git commitment statistics due to a terrific count of lines added by it.

@bl00mber bl00mber requested a review from npm/cli-team as a code owner Apr 5, 2019

@bl00mber bl00mber changed the base branch from latest to release-next Apr 5, 2019

Show resolved Hide resolved lib/shrinkwrap.js Outdated

@bl00mber bl00mber force-pushed the bl00mber:patch-pretty-print branch from c08b2ee to f5f895b Apr 6, 2019

@isaacs

This comment has been minimized.

Copy link
Member

isaacs commented Apr 12, 2019

I have mixed feelings about this.

While it's fair that it's not primarily intended to be consumed by humans, I do typically review the changes in it, just to make sure I'm tracking which packages are added to my tree. In cases where a dep (or meta-dep) causes a test to break, I've even gotten some value in git-bisecting over its history to find the problem.

I'd also challenge the "severely corrupting" angle. Modifying the dependency tree on a project is kind of a big deal. Tracking lines in package-lock.json is sort of a middle ground between tracking the entirety of node_modules and the "yolo" approach of times past. One way to frame this is that, since deps typically make up 97% or so of LoC in an application, updating deps is a bit of Real Work just as much (or more than) modifying lines of code in the project itself.

@bl00mber

This comment has been minimized.

Copy link
Author

bl00mber commented Apr 12, 2019

@isaacs perhaps I should add some option to enable pretty-print? I suppose majority of developers (~80-97%) never read this file. The work connected with updating the deps is tracking in the other files (package.json and files of the project if updating had caused any bugs with compatibility issues, which often fixed by rewriting the code of a project itself). Also, all modern code editors have pretty-print built-in or plugged-in code prettifiers, so if someone wants to read this he can do it as well. If the process of updating the dependencies had included some other work, that work is not related to the code directly. For example, the process of creating an architecture of the project before implementing it do not tracked by git entirely, despite being a serious part of work. Of course, there is a lot of other package managers and tools corrupting git statistics, but the npm is a 1st package manager (yarn downloads is 0.08% of npm's) of the 1st used programming language in the web, and package-lock.json is a required file in each project, this is probably a billions of package-lock.json files committed every week.

@ljharb

This comment has been minimized.

Copy link
Contributor

ljharb commented Apr 12, 2019

(ftr, it's not required; it's just enabled by default - package-lock=false in .npmrc disables it)

Show resolved Hide resolved lib/shrinkwrap.js Outdated

@bl00mber bl00mber force-pushed the bl00mber:patch-pretty-print branch from f5f895b to 3452c48 Apr 16, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.