> you just want to see that the file changed

I check the diff for uv.lock (Python counterpart of package-lock.json) every time I merge a PR. It is important to know which direct or transient dependencies have been updated. We don't blindly bump all dependencies to the latest versions (you shouldn't either).

If your diffs are too large to review your project structure needs change. I go by the broad statement that EVERY line should be read, understood and explainable by the developer.

For critical files like package-lock.json I'd also expect developers to explain why a library was added or a version was changed and the impact of the version change. The lack of such basic hygiene is why supply chain attacks are so common these days.

But it's not always massive, it's a good practice to see what the diff is and ensure there is no weird dependency (aka supply chain attack) showing up in there.

Are you saying "as a developer, you don't want to see what code you ship as transitive dependencies"?

I guess it's the norm in the software industry, but that's slightly irresponsible.

You know what’s bad DX? Your company’s product having a massive security breach, people stop using it, and having to lay off all the software engineers

DX = ? Developer experience maybe?

The point is that it should not be massive.

It's a CLI. DX is not the only concern. What about scripts that expect the default git behavior?

You could argue "those scripts are dumb then! outta my way!", but then you shouldn't be using a CLI for whatever it is you're trying to do. If you insist, you can just grep or use the --stat option.

We already know the git CLI has plenty of antifeatures like this. It is up to the devs how they want to proceed, but it doesn't change the fact that hiding things is a footgun.