linebreak-style without an argument seems to default to 'unix'

[denizdogan]

I have a Git project which I contribute to on a Windows system. The general consensus seems to be that we should use core.autocrlf to deal with any line-ending issues that might arise. Therefore we need to configure ESLint (actually XO, which uses ESLint) to allow either CRLF line-endings or LF line-endings as long as we're being consistent.

I have a project which I've configured like this:

  "xo": {
    "esnext": true,
    "rules": {
      "linebreak-style": 2,
      "camelcase": 1,
      "no-useless-constructor": 1
    }
  }

Now I get this error for every single line of my project:

131:16 error Expected linebreaks to be 'LF' but found 'CRLF' linebreak-style

The documentation talks about disallowing mixing of CRs and LFs, but it doesn't say explicitly whether my use case is supported. The test cases just leave me more confused, because their implementation seems to suggest that defaulting to LF-only is the intended behavior.

Is this a bug? How is this option meant to be used?

[alberto]

Yes, by default, unix style (LF) is assumed, as mentioned in the options section, so it's not a bug.

There is no option to run this rule as consistent.

[denizdogan]

Okay, got it. The documentation is phrased in ways that imply that something like consistent was the original intent of the rule.

1. The title says "Disallow mixing CRLF and LF". (I took this to mean within one file, not across multiple files...)
2. The first code example gives the impression that by default the rule detects mixing of CRLF and LF within files, but what it does in this case is just detect CRLFs.
3. "consistent line endings independent of operating system, VCS or editor used" - not really sure what the emphasized part is trying to clarify, maybe it could be replaced by "across multiple files"?

Maybe someone could look over the documentation and try to clarify the rule?

[alberto]

Agreed.