Skip to content

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

@kachkaev

Description

@kachkaev

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!

Metadata

Metadata

Assignees

No one assigned

    Labels

    locked-due-to-inactivityPlease open a new issue and fill out the template instead of commenting.status:has prIssues with an accompanying pull request. These issues will probably be fixed soon!type:option requestIssues requesting a new option. We generally don’t accept these unless there is technical necessity.

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions