An option to enforce certain line endings (LF / CRLF)

My issue is opposite to #92, which was closed by #472.

Our team uses Macs and Windows machines to work on the same code base and we struggle to enforce Unix-style line endings in the central repo. Time and again a person on Windows commits a file with CRLF instead of LF despite that we’re using multiple methods to prevent that. These include:

• git config --global core.autocrlf false in contributing instructions (this does not help if the repo has already been checked-out with CRLF)
• * text=auto eol=lf in the repo’s .gitattributes (not sure how this works)
• .vscode/settings.json that includes "files.eol": "\n" (not everyone uses vscode)
• husky + lint-staged as in Prettier instructions (this helps commit clean code, but does not fix line endings)
• A CI/CD task that runs prettier-check for the same file pattern as we have in lint-staged (it passes even if some files use lf and some crlf)

All the above measures do not stop a contributor from creating a new file with CRLF and committing it as is. Not setting git config --global core.autocrlf false moves the issue to another place: now a Windows user can check out the files in cmd.exe or SourceTree (LF → CRLF on checkout) and commit them via Ubuntu terminal (CRLF are preserved).

Prettier could really help us here if it had an option to enforce a certain flavour of line endings. I know that new options are not welcomed in general, but I can’t really see a good workaround. The only thing that comes to my mind is to tweak our package.json somewhat like this:

   "lint-staged": {
     "complex-file-pattern-for-files-that-get-prettified": [
       "prettier --write",
+      "some-npm-module-that-converts-crlf-to-lf-for-a-given-file",
       "git add"
     ]
   },

This will serve as an additional barrier to not committing CRLF, however, it’s not 100% robust. Someone can disable git hooks once and thus get CRLFs trough. prettier-check task in CI will not catch that. CRLFs will live in the central repo until someone check outs the latest commit, searches for \r in all code and makes another commit.

It feels like setting the flavour of new lines is a part of making the code prettier. So what do you think folks?

prettier --eol=lf path/to/file.js

# .prettierrc or .prettierrc.yaml
eol: lf

Accepted eol values: lf, crlf, auto (default).

PS: If there is any chance to get this approved and squeezed into upcoming 1.15, I’ll do my best to help!

[kachkaev]

@evilebottnawi I did not know that Prettier reads stuff from .editorconfig – that’s interesting! If so, I agree that the value for eol can be grabbed from it (it’s called end_of_line there).

We are not using .editorconfig file in our code base as it requires every contributor to have a plugin in their editors. This is quite challenging given the variety of tools and different backgrounds team members have (contributors can even commit from a web UI by just copy-pasting something). In any case, .editorconfig alone does not help us enforce things via git hooks or detect CRLFs in CI/CD. However, it does not mean that other Prettier users cannot benefit from reading eol value from this file.

I can submit a proof-of-concept PR for the EOL option if there are no strong objections (eol: auto | lf | cr | crlf). No worries if it gets rejected later on! If we come up with any other solution that would help repo owners avoid unwanted CRLFs in git history, I’ll be totally happy to take a clean and robust alternative on board 😉

[duailibe]

Whatever, this is not a hill I’m willing to die on; it just seemed pretty obvious to me that this doesn’t make sense to be in Prettier itself and could be a simply external tool, but maybe I’m wrong.

Wouldn’t you want to clrf-fix more files than Prettier can format?

Personally, this is another hint that this shouldn’t belong in Prettier

FTR ESLint can fix this https://eslint.org/docs/rules/linebreak-style