Search code examples
reactjsvisual-studio-codeprettier

change CRLF to LF in VSCode because eslint give me error

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

Solution

  • 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.