Xo: Default behavior on Windows is to report a failure for every line of every file due to linebreak-style and CRLF

[DavidAnson]

The default behavior of Windows and git on Windows is to use the CRLF pair for line endings. The default behavior of XO on Windows is to report a linebreak-style violation for every line of code in a typical project.

Although it is possible to change the default behavior of git or via .gitattributes, many tools on Windows do not handle LF-only endings well (and not all projects use git).

The most practical workaround seems to be to disable linebreak-style via xo.rules.linebreak-style in package.json, but this is discouraged by the documentation.

The general experience seems a bit harsh and may discourage new users from continuing.

Two solutions come to mind:

1. Disable the linebreak-style rule by default in XO
2. Create a top-level linebreak setting in XO (like space and semicolon)

One of the primary appeals of XO is that it is configuration-free. However, the default behavior means that will rarely be possible on Windows.

D:\T>git clone https://github.com/sindresorhus/cat-names.git
Cloning into 'cat-names'...

D:\T>cd cat-names

D:\T\cat-names>npm install [email protected]

D:\T\cat-names>node_modules\.bin\xo

  index.js:1:14
  ×   1:14  Expected linebreaks to be LF but found CRLF.           linebreak-style
  ×   2:56  Expected linebreaks to be LF but found CRLF.           linebreak-style
  ×   3:44  Expected linebreaks to be LF but found CRLF.           linebreak-style
  ×   4:1   Expected linebreaks to be LF but found CRLF.           linebreak-style
  ×   5:24  Expected linebreaks to be LF but found CRLF.           linebreak-style
  ×   6:46  Expected linebreaks to be LF but found CRLF.           linebreak-style

  ...

  39 errors

[sindresorhus]

many tools on Windows do not handle LF-only endings well (and not all projects use git).

What tools? I've never experienced problems with LF on Windows (except having to configure Git, but that's easy).

[DavidAnson]

Checking the state of the world as I write this reply, I find things are better than they used to be. (Yay!)

However:

The default text editor, notepad.exe, shows everything in an LF-only file on one long, unusable line.

The default for all new files is CRLF, such as those created on the command-line: dir > CRLF.txt or in editors like VS Code, etc..

PowerShell can read LF files, but it outputs CRLF by default (as above): Get-Content "LF.txt" | Set-Content "CRLF.txt".

And we've covered the default git behavior that needs to be changed. There are many articles about how to do so on the web - which seems like a sign people have trouble understanding/doing so.

It's possible to adopt an LF-only approach on Windows, but it feels like that's swimming upstream.

What are the arguments in favor of using LF-only?

[jongalloway]

Github's documentation and defaults recommend autocrlf and gitattributes. I'm pretty sure a default GitHub for Windows install, for instance, will have autocrlf set true by default, so if they just checkout a repo and make no changes, their files will have CRLF for EOL and lint will fail even though a checkin would work fine since git / gitattributes would handle the autocrlf conversion.

[dinoboff]

The source should have one line break style. Either a linter should report an error or git should convert line breaks. Switching the line break style to CRLF is not a solution; you will have the opposite problem.

XO or eslint could maybe disable this rules if the file is in a git repository with autocrlf on.

[sholladay]

This bit one of my engineers recently who works on Windows. I submitted a fix for it to ESLint itself, but they were unwilling.

XO could adopt my very trivial workaround. There is one silly gotcha brought up in the discussion with the ESLint folks: if a Windows developer does npm publish on a CLI with a shebang, the shebang may not work correctly for users due to the presence of CRLF. I consider that a corner case worth having for this, but they aren't.

I can envision solving the corner case with either

• A plugin that checks for shebangs specifically.
• Protection built into np to avoid publishing broken things.

[ScottFreeCode]

...if a Windows developer does npm publish on a CLI with a shebang, the shebang may not work correctly for users due to the presence of CRLF.

This seems to be an NPM issue: https://github.com/npm/npm/issues/12371; I have one of the two desired fixes attempted: https://github.com/npm/npm/pull/16634... There's also similar a compatibility problem with --no-bin-links and file permissions, though: https://github.com/npm/npm/issues/16645

[mastilver]

I used to have this kind of issue, just add the following .gitattributes to the root of your project:

* text=auto
*.js text eol=lf

[sholladay]

I was reluctant, but I am now using the .gitattributes pattern as well, instead of dynamically changing the XO config for each platform. Less things break than I thought on Windows with Unix-style linebreaks. And most Windows developers I know are moving towards the Windows Subsytem for Linux now that it is more stable, which always uses Unix linebreaks. I've come to the conclusion that it's "good enough" to enforce the consistency through git in most circumstances.