Add CRLF EOL for Window-specific file formats and add diffs

[david-fong]

Note on package.json:

• npm detects what line endings are used fix: use detect-newline to detect newline instead of default \n npm/npm#19904
• yarn uses the os line endings Infer EOLs from existing file or use OS EOL yarnpkg/yarn#1911
• pnpm currently (v5.18.11 as of this writing) enforces lf

Therefore, the line specifying package.json to use eol=lf is for pnpm and not needed for npm and yarn.

[david-fong]

@Richienb I learned more about how npm and yarn handle line endings for package.json. I updated the description. Can you take a look and weigh in on whether you think this template should simply go with lf for everything or alternatively add a comment that lf should be specified if using pnpm?

Also, since this PR for npm npm/npm#19904 got merged in 2018, I think it may be okay to remove the eol specifier I added for package-lock.json. I just tested it: npm creates a package-lock.json with lf by default, but if you switch it to crlf (like it would be fore someone who checks out the repo) and then perform an action that modifies the lockfile, npm goes along with the crlf. What do you think?

[Richienb]

Unless absolutely required, we shouldn't restrict files to specific line endings.

[devinrhode2]

Why not just keep it simple and consistent? package.json needs to be converted to LF, so why not also convert package-lock.json to LF?

[devinrhode2]

Until about March 18th 2018 npm would normalize to LF, so to be compatible with older versions of npm, normalizing to LF would be better IMO.

I'd say, if the be-all end-all to .gitattributes files causes files to be normalized to LF, then, I'll trust that project has made the right decision, and commit this to the repo.

If we allow LF or CRLF, if someone is working on a project that may have already normalized to LF, and is using windows, they could end up in a situation where they are accidentally changing EOL to CRLF

I sort of look to this project to just handle all CRLF/LF issues.. I am happy to see EOL normalized almost completely to LF, but some people more unfamiliar with EOL changes in git may be more confused.

..Now, if we have to convert package.json to LF for consistency with package managers, why not also be compatible with npm@5 and convert package-lock.json to LF?