4

Why do I have to manually for every file change "CRLF" to "LF" to make eslint(prettier) warning go away?.

Can there be a problem with this approach when committing and other users load the file in their respective environment. As you see on the image I get "eslint": "^6.6.0" complaint and when I toggle the down right "CRLF" to "LF" then eslint(prettier) is happy.

Can this be a problem later?

enter image description here enter image description here

Kid
  • 1,869
  • 3
  • 19
  • 48
  • @IMSOP then answer the question if you want to help – Kid Aug 27 '20 at 15:39
  • To be honest, I'm not totally sure what the question is - what kind of problems do you think there might be? By "other users" do you mean people collaborating on this code with you? People using this code if you publish it as a library? – IMSoP Aug 27 '20 at 15:40
  • I'm a beginner and asked if changing "CRLF" to "LF" would change the file encoding so it would look strange on other systems. And also using the eslint and prettier why do I have to for every *.js file click to change the "CRLF" to "LF" – Kid Aug 27 '20 at 17:17
  • "CRLF" and "LF" aren't what's generally referred to as "file encoding" - that would be things like "ASCII", "ISO-8859", and "UTF-8". Again, your comments suggest that a quick online search for "CRLF" might give you a clearer idea of what this setting does; or if you've already done that, an [edit] to clarify what you already know would be helpful. I don't want to spend time writing an answer that either repeats what you already know, or repeats things you _could_ know with a quick search. Does the tool that's recommending this change have any documentation of why it's recommending it? – IMSoP Aug 27 '20 at 17:37
  • The tool is not recommending it, I google myself to find the "CRLF" and "LF" to make the eslint stop complaining – Kid Aug 27 '20 at 18:42
  • Your screenshot shows the tool recommending you make a change, and a quick search shows me that both [eslint](https://eslint.org/docs/rules/linebreak-style) and [prettier](https://prettier.io/docs/en/options.html#end-of-line) have help pages explaining it. While searching for those I also found [this existing Stack Overflow question](https://stackoverflow.com/questions/53516594/why-do-i-keep-getting-delete-cr-prettier-prettier) which can probably be considered a duplicate. – IMSoP Aug 27 '20 at 18:54
  • @IMSoP Thanks I have seen that question(and read 10 other before I posted) and it does not apply to my problem. The accepted answer say "Try setting the "endOfLine":"auto" in your .prettierrc file (inside the object)" but my [prettierrc file](https://snipboard.io/YTX6Ww.jpg) does not look like that I have no rules object. Please post an answer if you have the answer so I can accept it – Kid Aug 28 '20 at 09:27
  • Again, I'm not really clear what your question _is_. Please can you [edit] your question to state more clearly what you already understand, and what you are trying to find out. – IMSoP Aug 28 '20 at 09:32
  • Why do I have to manually for every file change "CRLF" to "LF" to make eslint(prettier) warning go away?. – Kid Aug 28 '20 at 09:37
  • It is related to https://stackoverflow.com/questions/53516594/why-do-i-keep-getting-delete-cr-prettier-prettier?r=SearchResults&s=1|315.4737 – Cláudio Jan 23 '21 at 23:57

1 Answers1

9

Line breaks are traditionally represented by two bytes (CR and LF) on DOS/Windows systems, and by only one (LF) on Unix/Linux systems. The rule you're seeing, documented for eslint here and for prettier here defaults to saying that all files should use the Unix convention (saying "delete CR" is equivalent to saying "convert CRLF to LF only") to ensure the code base is consistent.

If all your files are currently CRLF, you have two options:

  • Configure eslint/prettier to standardise on "crlf" / "windows" instead (or disable the rule completely).
  • Change the line endings on your files from CRLF to LF. That could be file by file using the setting you show, by running a command-line tool like dos2unix, or by configuring prettier to fix the problem automatically.

As well as fixing your existing files, you might want to look at why they're showing up that way:

  • Ensure VSCode is configured to create new files with Unix / LF line endings by default
  • git has a "feature" that by default checkouts created on Windows will convert LF to CRLF every time you checkout, and convert them back when you commit. Since any decent code editor will cope with LF line endings just fine (even Notepad supports them now!) you should turn this off with git config core.autocrlf false

As for how this will affect other people:

  • If you change the line endings of files in a shared repo, this will show up as a change to every line in the version history. This is mostly a one-off nuisance, and creates a bit of noise when you're looking at the history of a file.
  • In the unlikely scenario someone's opening the file in a tool that only supports CRLF line endings, they'll have problems opening it. They can work around it with the above-mentioned core.autocrlf setting, or by using a better tool.
IMSoP
  • 89,526
  • 13
  • 117
  • 169