Is the plan to visualize end of line in every snapshot? Shall most of the test files be turned to LF for consistency?

It’d be great if Prettier repo could follow endOfLine: lf itself with few exceptions when CRLF testing is needed. This cleanup comes at a cost of breaking git blame though.

Some initial thoughts:

• Replace all CRLF with LF in this repo
• Set * text=auto in .gitattributes. If I understand correctly, it allows us to have consistent LF on Unix and consistent CRLF on Windows.

  (https://stackoverflow.com/a/38017715)
  text=auto: when someone commits a file, Git guesses whether that file is a text file or not, and if it is, it will commit a version of the file where all CR + LF bytes are replaced with LF bytes. It doesn't directly affect what files look like in the working tree, there are other settings that will convert LF bytes to CR + LF bytes when checking out a file.

• Visualize whitespaces for comparison (i.e., expect(visualize(a)).toEqual(visualize(b))), we could observe their diffs if the test failed.
• Jest normalizes line endings for snapshots so we don't need to handle it. (no visualization)

Seems like Azure Pipelines didn’t run for some reason.

Jest normalizes line endings for snapshots so we don't need to handle it.

Jest simply kills all CRs in snapshots – see its normalizeNewlines() function. We can't really check CR/CRLF with this, and this is why replace(/\r/g, "/*CR*/") was necessary. Perhaps, we could use visualizeEndOfLine() in snapshots too?

Set * text=auto in .gitattributes.

I believe it should be * text=auto eol=lf, followed by a couple of specific rules with eol=crlf / eol=crlf for some CRLF test files. Alternatively, these specific .gitattributes can go directly to folders with particular tests. And yes, in this case all source files and the majority of test files will need to be converted from CRLF to LF at a cost of 'losing' git blame on master.

Ideally, all files on all operating systems should be checked-out with identical line endings, regardless of git config --global core.autocrlf XXX. This can be checked in CI too.

@j-f1 Its message looks confusing but it actually works, you need to click it to see the detail logs.

@kachkaev

Jest simply kills all CRs in snapshots – see its normalizeNewlines() function. We can't really check CR/CRLF with this, and this is why replace(/\r/g, "/*CR*/") was necessary. Perhaps, we could use visualizeEndOfLine() in snapshots too?

I meant, the CRLF/LF checks are done in expect(visualize(a)).toEqual(visualize(b)), snapshots are used for visible records. And that's also the reason why I don't want to use eol=lf, I'd like to use CRLF on our Windows CI to test CRLF.

Or maybe we should use eol=lf and add another test to replace LF with CRLF before formatting?

IMO we can use eol=lf in the whole repo except a couple of test files where we're checking endOfLine option.

Based on #5498 (comment), it seems we should revert 38bfa05, but I'm not sure how to deal with those bad unicode. Should we use <CRLF> instead of ↵?

copied a couple of comments from #5498 as asked by @ikatyang

We shouldn't need to configure global settings and we should be able to test CRLF locally even if it's on LF system (via TEST_CRLF).

Testing on Windows machines with globally configured CRLF and LF in git is what I meant. This can be useful because Windows folks have different preferencess and all of them should be able to contribute to Prettier without problems of running local tests. By default, git’s core.autocrlf is true, but some devs set it to false, e.g. create-react-app contribution guidelines recommend doing so.

I did not know Azure pipelines had a flag for CRLF, interesting!

Running tests on a Windows machine with LF ia different than doing this on Linux, because on Windows os.EOL is CRLF regardless of how git is configured. Some modules refer to this value and this can affect what Prettier generates in the end.

Updated the OP to reflect the changes, ready for review.
(Most of the diffs are line ending normalization, just ignore them.)