-
-
Notifications
You must be signed in to change notification settings - Fork 4.7k
An option to enforce certain line endings (LF / CRLF) #5320
Copy link
Copy link
Closed
Labels
locked-due-to-inactivityPlease open a new issue and fill out the template instead of commenting.Please 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!Issues 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.Issues requesting a new option. We generally don’t accept these unless there is technical necessity.
Milestone
Metadata
Metadata
Assignees
Labels
locked-due-to-inactivityPlease open a new issue and fill out the template instead of commenting.Please 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!Issues 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.Issues requesting a new option. We generally don’t accept these unless there is technical necessity.
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 falsein contributing instructions (this does not help if the repo has already been checked-out with CRLF)* text=auto eol=lfin the repo's.gitattributes(not sure how this works).vscode/settings.jsonthat includes"files.eol": "\n"(not everyone uses vscode)husky+lint-stagedas in Prettier instructions (this helps commit clean code, but does not fix line endings)prettier-checkfor the same file pattern as we have inlint-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 falsemoves 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.jsonsomewhat 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-checktask in CI will not catch that. CRLFs will live in the central repo until someone check outs the latest commit, searches for\rin 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?
Accepted
eolvalues: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!