3

I suppose there's no hard answer here, but would like to know how others deal with diff being messed up when committing package-lock.json into their node repo.

So far most opinions seem to favor committing package-lock.json - ensure the exact same versions of dependency are installed anywhere and everywhere (See Do I commit the package-lock.json file created by npm 5? ). But it has messed up diff tool each time I upgrade npm dependencies. The code frequency visualization tool on Github is basically useless since I started to commit package-lock.json.

As an example, the two inflated spikes from the graph below were the result of the changes in package-lock.json triggered by mere npm update. code frequency visualization

Is there any way to mitigate this? or should I remain indifferent to this downside?

Hank Chan
  • 1,706
  • 1
  • 16
  • 21
  • 2
    One option that I've used to great comfort is to use fixed version numbers in `package.json` and ignore the lockfile. If you need to update things, do it in one pass every now and then. – Etheryte Sep 15 '18 at 20:30
  • @nicholas while that solves the "problem" it introduces instability. – Jonas Wilms Sep 15 '18 at 20:30
  • 2
    @nicholas by default, `npm install package` its version gets added as `^1.0.0` so whenever someone else installs without a lock file and a newer version is available, that gets installed. If something has changed in that version, e.g. the server suddenly crashes while it runs without problems on localhost (had that twice last year, then pinned all dependencies) – Jonas Wilms Sep 15 '18 at 20:33
  • 1
    @JonasWilms Even more devious is that even though you may have fixed version numbers in your own package.json, any dependencies you have may not have fixed versions in theirs, which in my case has led to instability. – Drak Aug 25 '22 at 07:55

1 Answers1

0

Why not just add package-lock.json to .gitignore. You can still commit the file without its changes being tracked.

See what official doc says:

Patterns which should be version-controlled and distributed to other repositories via clone (i.e., files that all developers will want to ignore) should go into a .gitignore file.

Patterns which a user wants Git to ignore in all situations (e.g., backup or temporary files generated by the user’s editor of choice) generally go into a file specified by core.excludesFile in the user’s ~/.gitconfig.

ImGroot
  • 796
  • 1
  • 6
  • 17
  • Hey, I'm not saying to keep the file outdated. You can still commit your changes manually. Because of `.gitignore` your changes will not be staged automatically but yes would be ignored by diff tool. – ImGroot Sep 15 '18 at 20:33
  • `git commit package-lock.json -m "Committing although ignored for tracking"` – ImGroot Sep 15 '18 at 20:35
  • This does not work with git version 2.34.1. When I execute `git difftool`, it shows me `package-lock.json`, even though it is in .gitignore. – Konrad Höffner Dec 16 '21 at 11:23