(Optionally) ignore lockfiles in contribution stats

[jojomatik]

I think it should be possible to ignore lockfiles such as package-lock.json in the contributors insights graph. Most (but not all) of the time changes to these files are automatically generated by the package manager (e.g. npm).

These lockfiles can become very large very fast (20.000+ lines is not uncommon), and so do changes to these files. In many of my projects these numbers skew the contributor graph, counting tens if not hundreds of thousands changed lines code on me without any real "intellectual input" from my side. Even though I usually review these changes before pushing, they usually originate from the package manager.

Manual changes to package-lock.json are, from my point of view, really rare and usually small.

I know these contribution stats are not really representative of the work and effort and value added anyways, but I don't think this should mean we shouldn't even try to make it a little bit better.

My proposal would be for GitHub to compile a list of files excluded by default and an option to include them (next to the already existing dropdown to change from "number of commits" to "additions" (lines of code)). This list of files propably already exists, as it usually tells me that changes to generated files are not shown by default whilst reviewing a PR.

Additionally I'd like to propose to change the default selection from "number of commits" to "additions".

What do other people think of this proposal?

Context: Post on the github community forum

[andrewring]

This is particularly important for PR change lines UI. If I open a PR that's huge, I'm not going to start reviewing it until I have a significant chunk of time. Having this stat wildly misleading can be quite harmful to standard workflows.

[iandunn]

I'd love to see this happen too. It should be applied retroactively as well, since we have years of misleading stats at this point.

[sheerlox]

This has been a huge issue for me, especially in the contributors section of a project. When adding/removing a few packages, you can easily get into the top contributors (sorted by addition/deletion), when the package-lock.json file is responsible for > 95% of your changed lines.
As Ian stated, this is misleading information and should be applied retroactively.

[chrisp-verana]

+1

[spenserblack]

My proposal would be for GitHub to compile a list of files excluded by default and an option to include them

Just an FYI that GitHub pretty much already has the necessary data tracked.
Here is the code that GitHub uses to detect a file as generated: https://github.com/github-linguist/linguist/blob/39fd5e93de98de3434cb3e857c5b1972c418f8c5/lib/linguist/generated.rb
And here are docs on how to override that behavior to mark a file as generated or not generated: https://github.com/github-linguist/linguist/blob/39fd5e93de98de3434cb3e857c5b1972c418f8c5/docs/overrides.md#generated-code

[uhon]

Are there plans to integrate above mentioned data into Github UI?
Would highly appreciate if PR change-summaries or user stats would not include package-lock.json

[spenserblack]

By default generated files' diffs are minimized in the PR diff view.

But some lock files are not marked as generated, like yarn.lock. If you go through linguist's issue and PR history you'll see that yarn's maintainer raised a discussion that yarn.lock should not be marked as generated because the file should be reviewed (github-linguist/linguist#4348).

But as far as any future plans are concerned, I don't really know.