Since package-lock.json is automatically generated by npm, is it possible for it to decide to use crlf endings? Otherwise, there would be no need for this rule.

I did run into a package-lock.json which has crlf endings, in a fairly new project

Simply normalizing to LF creates better cross-platform compatibility - better compatibility with npm < 6, yarn 2+3, and future versions of pnpm, should pnpm decide to follow yarns decision to utilize package-lock.json. Since npm 5 had already started normalizing to LF, and package.json needs to be LF, why not also make package-lock.json also LF for consistency.

I kind of look to this project to simply handle all EOL issues. So, if someone also has that same perspective, adds this .gitattributes, see's some EOL changes, I'm comfortable committing them. But, if package-lock.json could be generated with ANY EOL char, then this creates noisy git history.

Often times to update javascript projects, we entirely remove the lockfile and re-generate it from scratch. On windows, it'll be crlf, leading to confusion when someone on mac checks out the same project.

(yes, latest versions of yarn will make use of package-lock.json in certain situations)

It's not extremely obvious what the best setting here is. There are quite a number of possible tools/editors/security scanners/etc that could touch package-lock.json.

Clearly at some point, npm@5 started generating package-lock.json with just LF

This was probably annoying for folks on windows

Now npm v6+ will respect what is currently in the file

In the javascript web dev ecosystem, mac/linux seem to be most popular, or at least have generally received the best tooling support. (I really value having projects work cross-platform, normalizing to LF just takes out all the guess-work)

Since package.json is also set to use lf, this is reasonable.