Do not pretty-print package-lock.json to prevent corrupting git lines count history by bl00mber · Pull Request #186 · npm/cli

bl00mber · 2019-04-05T23:13:59Z

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.

isaacs · 2019-04-12T20:05:10Z

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 · 2019-04-12T22:30:14Z

@isaacs should I add some option to enable pretty-print? I suppose significant percentage of projects (~80-97%) not using this file much. 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 · 2019-04-12T22:36:51Z

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

… count history

dominictarr · 2019-05-08T10:15:02Z

there is a postshrinkwrap script that you could use to de-pretty print the npm-shrinkwrap.json file... I'm not sure if it runs on package-lock though (I'm generally confused by the different behaviour between these two, tbh)

bl00mber · 2019-05-08T19:38:01Z

@dominictarr yes, this file can be modified with the use of external scripts. The issue is about default behavior. When someone adds or updates a dependency and sends a PR it is causing a mess in consistency of development history.

rhendric · 2019-07-08T16:24:39Z

Please, no. A pretty-printed package-lock.json is much more likely to be successfully automatically merged or rebased by git than one that's all in one line. Having the option to switch back to the multiline format after the fact isn't much help the first time you try to merge a PR containing a change to unrelated dependencies. If this became the default, both project owners and submitters of PRs to other projects would find any change to project dependencies a lot more obnoxious.

(Of course there are cases even with pretty-printing when the only way to merge package-lock.json is to blow it away and regenerate it locally. But these cases aren't all cases, as they would be if package-lock.json defaulted to a single line format.)

isaacs · 2019-07-08T16:46:43Z

Yeah, I'm inclined to say no on this, having thought about it a bit more. I get the reasoning behind it, and I'd be open to an option to disable pretty-printing, but the current default is the best default for most cases.

npm-merge-driver is a nice tool to handle merge conflicts in the vast majority of cases, but would be much less effective if the JSON was all on one line.

bl00mber · 2019-07-12T20:15:51Z

@isaacs so if I am allowed to suggest this non-default option I should open another PR?

isaacs · 2019-07-12T20:58:28Z

@bl00mber Sure, that's fine.

…m#186) * fix(setup): drain stale keypresses between TUI screen transitions The picker's vim-style j/k navigation can leave buffered keypresses in crossterm's event queue that leak into the next input field, corrupting pre-populated values like client_id. * refactor: extract drain logic into helper, add changeset

bl00mber · 2019-04-05T23:13:59Z

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.

isaacs · 2019-04-12T20:05:10Z

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 · 2019-04-12T22:30:14Z

@isaacs should I add some option to enable pretty-print? I suppose significant percentage of projects (~80-97%) not using this file much. 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 · 2019-04-12T22:36:51Z

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

… count history

dominictarr · 2019-05-08T10:15:02Z

there is a postshrinkwrap script that you could use to de-pretty print the npm-shrinkwrap.json file... I'm not sure if it runs on package-lock though (I'm generally confused by the different behaviour between these two, tbh)

bl00mber · 2019-05-08T19:38:01Z

@dominictarr yes, this file can be modified with the use of external scripts. The issue is about default behavior. When someone adds or updates a dependency and sends a PR it is causing a mess in consistency of development history.

rhendric · 2019-07-08T16:24:39Z

Please, no. A pretty-printed package-lock.json is much more likely to be successfully automatically merged or rebased by git than one that's all in one line. Having the option to switch back to the multiline format after the fact isn't much help the first time you try to merge a PR containing a change to unrelated dependencies. If this became the default, both project owners and submitters of PRs to other projects would find any change to project dependencies a lot more obnoxious.

(Of course there are cases even with pretty-printing when the only way to merge package-lock.json is to blow it away and regenerate it locally. But these cases aren't all cases, as they would be if package-lock.json defaulted to a single line format.)

isaacs · 2019-07-08T16:46:43Z

Yeah, I'm inclined to say no on this, having thought about it a bit more. I get the reasoning behind it, and I'd be open to an option to disable pretty-printing, but the current default is the best default for most cases.

npm-merge-driver is a nice tool to handle merge conflicts in the vast majority of cases, but would be much less effective if the JSON was all on one line.

bl00mber · 2019-07-12T20:15:51Z

@isaacs so if I am allowed to suggest this non-default option I should open another PR?

isaacs · 2019-07-12T20:58:28Z

@bl00mber Sure, that's fine.

…m#186) * fix(setup): drain stale keypresses between TUI screen transitions The picker's vim-style j/k navigation can leave buffered keypresses in crossterm's event queue that leak into the next input field, corrupting pre-populated values like client_id. * refactor: extract drain logic into helper, add changeset

bl00mber · 2019-04-05T23:13:59Z

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.

isaacs · 2019-04-12T20:05:10Z

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 · 2019-04-12T22:30:14Z

@isaacs should I add some option to enable pretty-print? I suppose significant percentage of projects (~80-97%) not using this file much. 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 · 2019-04-12T22:36:51Z

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

… count history

dominictarr · 2019-05-08T10:15:02Z

there is a postshrinkwrap script that you could use to de-pretty print the npm-shrinkwrap.json file... I'm not sure if it runs on package-lock though (I'm generally confused by the different behaviour between these two, tbh)

bl00mber · 2019-05-08T19:38:01Z

@dominictarr yes, this file can be modified with the use of external scripts. The issue is about default behavior. When someone adds or updates a dependency and sends a PR it is causing a mess in consistency of development history.

rhendric · 2019-07-08T16:24:39Z

Please, no. A pretty-printed package-lock.json is much more likely to be successfully automatically merged or rebased by git than one that's all in one line. Having the option to switch back to the multiline format after the fact isn't much help the first time you try to merge a PR containing a change to unrelated dependencies. If this became the default, both project owners and submitters of PRs to other projects would find any change to project dependencies a lot more obnoxious.

(Of course there are cases even with pretty-printing when the only way to merge package-lock.json is to blow it away and regenerate it locally. But these cases aren't all cases, as they would be if package-lock.json defaulted to a single line format.)

isaacs · 2019-07-08T16:46:43Z

Yeah, I'm inclined to say no on this, having thought about it a bit more. I get the reasoning behind it, and I'd be open to an option to disable pretty-printing, but the current default is the best default for most cases.

npm-merge-driver is a nice tool to handle merge conflicts in the vast majority of cases, but would be much less effective if the JSON was all on one line.

bl00mber · 2019-07-12T20:15:51Z

@isaacs so if I am allowed to suggest this non-default option I should open another PR?

isaacs · 2019-07-12T20:58:28Z

@bl00mber Sure, that's fine.

…m#186) * fix(setup): drain stale keypresses between TUI screen transitions The picker's vim-style j/k navigation can leave buffered keypresses in crossterm's event queue that leak into the next input field, corrupting pre-populated values like client_id. * refactor: extract drain logic into helper, add changeset

bl00mber · 2019-04-05T23:13:59Z

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.

isaacs · 2019-04-12T20:05:10Z

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 · 2019-04-12T22:30:14Z

@isaacs should I add some option to enable pretty-print? I suppose significant percentage of projects (~80-97%) not using this file much. 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 · 2019-04-12T22:36:51Z

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

… count history

dominictarr · 2019-05-08T10:15:02Z

there is a postshrinkwrap script that you could use to de-pretty print the npm-shrinkwrap.json file... I'm not sure if it runs on package-lock though (I'm generally confused by the different behaviour between these two, tbh)

bl00mber · 2019-05-08T19:38:01Z

@dominictarr yes, this file can be modified with the use of external scripts. The issue is about default behavior. When someone adds or updates a dependency and sends a PR it is causing a mess in consistency of development history.

rhendric · 2019-07-08T16:24:39Z

Please, no. A pretty-printed package-lock.json is much more likely to be successfully automatically merged or rebased by git than one that's all in one line. Having the option to switch back to the multiline format after the fact isn't much help the first time you try to merge a PR containing a change to unrelated dependencies. If this became the default, both project owners and submitters of PRs to other projects would find any change to project dependencies a lot more obnoxious.

(Of course there are cases even with pretty-printing when the only way to merge package-lock.json is to blow it away and regenerate it locally. But these cases aren't all cases, as they would be if package-lock.json defaulted to a single line format.)

isaacs · 2019-07-08T16:46:43Z

Yeah, I'm inclined to say no on this, having thought about it a bit more. I get the reasoning behind it, and I'd be open to an option to disable pretty-printing, but the current default is the best default for most cases.

npm-merge-driver is a nice tool to handle merge conflicts in the vast majority of cases, but would be much less effective if the JSON was all on one line.

bl00mber · 2019-07-12T20:15:51Z

@isaacs so if I am allowed to suggest this non-default option I should open another PR?

isaacs · 2019-07-12T20:58:28Z

@bl00mber Sure, that's fine.

…m#186) * fix(setup): drain stale keypresses between TUI screen transitions The picker's vim-style j/k navigation can leave buffered keypresses in crossterm's event queue that leak into the next input field, corrupting pre-populated values like client_id. * refactor: extract drain logic into helper, add changeset

bl00mber · 2019-04-05T23:13:59Z

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.

isaacs · 2019-04-12T20:05:10Z

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 · 2019-04-12T22:30:14Z

@isaacs should I add some option to enable pretty-print? I suppose significant percentage of projects (~80-97%) not using this file much. 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 · 2019-04-12T22:36:51Z

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

… count history

dominictarr · 2019-05-08T10:15:02Z

there is a postshrinkwrap script that you could use to de-pretty print the npm-shrinkwrap.json file... I'm not sure if it runs on package-lock though (I'm generally confused by the different behaviour between these two, tbh)

bl00mber · 2019-05-08T19:38:01Z

@dominictarr yes, this file can be modified with the use of external scripts. The issue is about default behavior. When someone adds or updates a dependency and sends a PR it is causing a mess in consistency of development history.

rhendric · 2019-07-08T16:24:39Z

Please, no. A pretty-printed package-lock.json is much more likely to be successfully automatically merged or rebased by git than one that's all in one line. Having the option to switch back to the multiline format after the fact isn't much help the first time you try to merge a PR containing a change to unrelated dependencies. If this became the default, both project owners and submitters of PRs to other projects would find any change to project dependencies a lot more obnoxious.

(Of course there are cases even with pretty-printing when the only way to merge package-lock.json is to blow it away and regenerate it locally. But these cases aren't all cases, as they would be if package-lock.json defaulted to a single line format.)

isaacs · 2019-07-08T16:46:43Z

Yeah, I'm inclined to say no on this, having thought about it a bit more. I get the reasoning behind it, and I'd be open to an option to disable pretty-printing, but the current default is the best default for most cases.

npm-merge-driver is a nice tool to handle merge conflicts in the vast majority of cases, but would be much less effective if the JSON was all on one line.

bl00mber · 2019-07-12T20:15:51Z

@isaacs so if I am allowed to suggest this non-default option I should open another PR?

isaacs · 2019-07-12T20:58:28Z

@bl00mber Sure, that's fine.

…m#186) * fix(setup): drain stale keypresses between TUI screen transitions The picker's vim-style j/k navigation can leave buffered keypresses in crossterm's event queue that leak into the next input field, corrupting pre-populated values like client_id. * refactor: extract drain logic into helper, add changeset

bl00mber · 2019-04-05T23:13:59Z

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.

isaacs · 2019-04-12T20:05:10Z

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 · 2019-04-12T22:30:14Z

@isaacs should I add some option to enable pretty-print? I suppose significant percentage of projects (~80-97%) not using this file much. 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 · 2019-04-12T22:36:51Z

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

… count history

dominictarr · 2019-05-08T10:15:02Z

there is a postshrinkwrap script that you could use to de-pretty print the npm-shrinkwrap.json file... I'm not sure if it runs on package-lock though (I'm generally confused by the different behaviour between these two, tbh)

bl00mber · 2019-05-08T19:38:01Z

@dominictarr yes, this file can be modified with the use of external scripts. The issue is about default behavior. When someone adds or updates a dependency and sends a PR it is causing a mess in consistency of development history.

rhendric · 2019-07-08T16:24:39Z

Please, no. A pretty-printed package-lock.json is much more likely to be successfully automatically merged or rebased by git than one that's all in one line. Having the option to switch back to the multiline format after the fact isn't much help the first time you try to merge a PR containing a change to unrelated dependencies. If this became the default, both project owners and submitters of PRs to other projects would find any change to project dependencies a lot more obnoxious.

(Of course there are cases even with pretty-printing when the only way to merge package-lock.json is to blow it away and regenerate it locally. But these cases aren't all cases, as they would be if package-lock.json defaulted to a single line format.)

isaacs · 2019-07-08T16:46:43Z

Yeah, I'm inclined to say no on this, having thought about it a bit more. I get the reasoning behind it, and I'd be open to an option to disable pretty-printing, but the current default is the best default for most cases.

npm-merge-driver is a nice tool to handle merge conflicts in the vast majority of cases, but would be much less effective if the JSON was all on one line.

bl00mber · 2019-07-12T20:15:51Z

@isaacs so if I am allowed to suggest this non-default option I should open another PR?

isaacs · 2019-07-12T20:58:28Z

@bl00mber Sure, that's fine.

…m#186) * fix(setup): drain stale keypresses between TUI screen transitions The picker's vim-style j/k navigation can leave buffered keypresses in crossterm's event queue that leak into the next input field, corrupting pre-populated values like client_id. * refactor: extract drain logic into helper, add changeset

bl00mber · 2019-04-05T23:13:59Z

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.

isaacs · 2019-04-12T20:05:10Z

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 · 2019-04-12T22:30:14Z

@isaacs should I add some option to enable pretty-print? I suppose significant percentage of projects (~80-97%) not using this file much. 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 · 2019-04-12T22:36:51Z

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

… count history

dominictarr · 2019-05-08T10:15:02Z

there is a postshrinkwrap script that you could use to de-pretty print the npm-shrinkwrap.json file... I'm not sure if it runs on package-lock though (I'm generally confused by the different behaviour between these two, tbh)

bl00mber · 2019-05-08T19:38:01Z

@dominictarr yes, this file can be modified with the use of external scripts. The issue is about default behavior. When someone adds or updates a dependency and sends a PR it is causing a mess in consistency of development history.

rhendric · 2019-07-08T16:24:39Z

Please, no. A pretty-printed package-lock.json is much more likely to be successfully automatically merged or rebased by git than one that's all in one line. Having the option to switch back to the multiline format after the fact isn't much help the first time you try to merge a PR containing a change to unrelated dependencies. If this became the default, both project owners and submitters of PRs to other projects would find any change to project dependencies a lot more obnoxious.

(Of course there are cases even with pretty-printing when the only way to merge package-lock.json is to blow it away and regenerate it locally. But these cases aren't all cases, as they would be if package-lock.json defaulted to a single line format.)

isaacs · 2019-07-08T16:46:43Z

Yeah, I'm inclined to say no on this, having thought about it a bit more. I get the reasoning behind it, and I'd be open to an option to disable pretty-printing, but the current default is the best default for most cases.

npm-merge-driver is a nice tool to handle merge conflicts in the vast majority of cases, but would be much less effective if the JSON was all on one line.

bl00mber · 2019-07-12T20:15:51Z

@isaacs so if I am allowed to suggest this non-default option I should open another PR?

isaacs · 2019-07-12T20:58:28Z

@bl00mber Sure, that's fine.

…m#186) * fix(setup): drain stale keypresses between TUI screen transitions The picker's vim-style j/k navigation can leave buffered keypresses in crossterm's event queue that leak into the next input field, corrupting pre-populated values like client_id. * refactor: extract drain logic into helper, add changeset

bl00mber · 2019-04-05T23:13:59Z

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.

isaacs · 2019-04-12T20:05:10Z

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 · 2019-04-12T22:30:14Z

@isaacs should I add some option to enable pretty-print? I suppose significant percentage of projects (~80-97%) not using this file much. 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 · 2019-04-12T22:36:51Z

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

… count history

dominictarr · 2019-05-08T10:15:02Z

there is a postshrinkwrap script that you could use to de-pretty print the npm-shrinkwrap.json file... I'm not sure if it runs on package-lock though (I'm generally confused by the different behaviour between these two, tbh)

bl00mber · 2019-05-08T19:38:01Z

@dominictarr yes, this file can be modified with the use of external scripts. The issue is about default behavior. When someone adds or updates a dependency and sends a PR it is causing a mess in consistency of development history.

rhendric · 2019-07-08T16:24:39Z

Please, no. A pretty-printed package-lock.json is much more likely to be successfully automatically merged or rebased by git than one that's all in one line. Having the option to switch back to the multiline format after the fact isn't much help the first time you try to merge a PR containing a change to unrelated dependencies. If this became the default, both project owners and submitters of PRs to other projects would find any change to project dependencies a lot more obnoxious.

(Of course there are cases even with pretty-printing when the only way to merge package-lock.json is to blow it away and regenerate it locally. But these cases aren't all cases, as they would be if package-lock.json defaulted to a single line format.)

isaacs · 2019-07-08T16:46:43Z

Yeah, I'm inclined to say no on this, having thought about it a bit more. I get the reasoning behind it, and I'd be open to an option to disable pretty-printing, but the current default is the best default for most cases.

npm-merge-driver is a nice tool to handle merge conflicts in the vast majority of cases, but would be much less effective if the JSON was all on one line.

bl00mber · 2019-07-12T20:15:51Z

@isaacs so if I am allowed to suggest this non-default option I should open another PR?

isaacs · 2019-07-12T20:58:28Z

@bl00mber Sure, that's fine.

…m#186) * fix(setup): drain stale keypresses between TUI screen transitions The picker's vim-style j/k navigation can leave buffered keypresses in crossterm's event queue that leak into the next input field, corrupting pre-populated values like client_id. * refactor: extract drain logic into helper, add changeset

bl00mber requested a review from a team as a code owner April 5, 2019 23:13

bl00mber changed the base branch from latest to release-nextApril 5, 2019 23:18

ljharb reviewed Apr 5, 2019
View reviewed changes

Comment threadlib/shrinkwrap.js Outdated

bl00mber force-pushed the patch-pretty-print branch from c08b2ee to f5f895bCompare April 6, 2019 14:08

denis-sokolov reviewed Apr 15, 2019
View reviewed changes

Comment threadlib/shrinkwrap.js Outdated

do not pretty-print package-lock.json to prevent corrupting git lines…
3452c48
… count history

bl00mber force-pushed the patch-pretty-print branch from f5f895b to 3452c48Compare April 16, 2019 03:53

isaacs added the needs-discussion label Jun 26, 2019

isaacs force-pushed the release-next branch 2 times, most recently from 896149d to 31718e7Compare June 29, 2019 21:55

isaacs closed this Jul 11, 2019

bl00mber mentioned this pull request Sep 9, 2019
Option to disable pretty-print of package-lock.json #248
Closed

snyk-bot mentioned this pull request Jul 13, 2022
[Snyk] Upgrade pacote from 13.6.0 to 13.6.1 LadyK-21/cli#11
Open

Mhmonicox mentioned this pull request Feb 15, 2023
[Snyk] Upgrade pacote from 13.1.1 to 13.6.2 Mhmonicox/cli#8
Open

Mhmonicox mentioned this pull request Jun 1, 2023
[Snyk] Upgrade pacote from 13.1.1 to 13.6.2 Mhmonicox/cli#13
Open

LadyK-21 mentioned this pull request Nov 29, 2023
[Snyk] Fix for 2 vulnerabilities LadyK-21/cli#13
Open

soloinovator mentioned this pull request Nov 29, 2023
[Snyk] Fix for 2 vulnerabilities soloinovator/cli#18
Open

LadyK-21 mentioned this pull request Mar 22, 2024
[Snyk] Fix for 1 vulnerabilities LadyK-21/cli#37
Open

soloinovator mentioned this pull request Mar 23, 2024
[Snyk] Fix for 1 vulnerabilities soloinovator/cli#43
Open

snyk-ioBot mentioned this pull request Oct 22, 2024
[Snyk] Fix for 55 vulnerabilities Graybar-codespace/cli-3#116
Open

github-actionsBot added a commit to Kevinlee7250/cli that referenced this pull request Jul 6, 2026
🤖 봇 응답 (npm#186)
8150ef1

github-actionsBot added a commit to Kevinlee7250/cli that referenced this pull request Jul 15, 2026
📊 blog1 게시 완료 (npm#186)
cdb7021

github-actionsBot added a commit to Kevinlee7250/cli that referenced this pull request Jul 15, 2026
📊 blog2 게시 완료 (npm#186)
079a0a8

github-actionsBot added a commit to Kevinlee7250/cli that referenced this pull request Jul 15, 2026
📊 blog3 게시 완료 (npm#186)
3ec29c8

github-actionsBot added a commit to Kevinlee7250/cli that referenced this pull request Jul 31, 2026
🔧 자동 수리 완료 (npm#186)
3d31d21

github-actionsBot added a commit to Kevinlee7250/cli that referenced this pull request Aug 16, 2026
🔥 트렌드 선점 후보 갱신 (npm#186)
b6f2651