Add 'native' as well as 'windows' and 'unix' to linebreak-style

This is a duplicate of request #8596, which already has a closed pull request #8620 which was designed to fix this. I realise this will therefore most likely be closed summarily, but I did just want to try to put the reasons for this change fowards again. I suspect that this may have been rejected by people who don’t have extensive experience of working on a projects where some developers are on Linux and some on Windows - because the approaches suggested as alternatives to allowing this fix really, truly, don’t work well.

I’ll try to be as brief as reasonably possible:

• If you don’t specify anything on git then it is easy to end up with a mixed Linux-Windows project which has mixed line endings in its files which (we all agree) is horrible
• For Linux-Windows projects on git, the standard approach to resolving this is to either set the git core.autocrlf config variable to true at the repository (or global) level or, even better (because it forces the equivalent of this setting on everyone who clones the repo), to have a .gitattributes file in the repo root containing the line * text=auto
• As we know, this results in all text files in the repo itself having LF line endings, but all text files checked out to Windows machines (only) appearing on Windows to have CRLF line endings, and with such files (and changes to them) checked back in again ‘magically’ as LF
• Mainly, this just works. We can also safely say there’s a reason the git developers did this, and that it’s the standard approach to this problem. Which is, mainly, that it just works.
• The advantages of it are:
  • All programs on the OS (even older ones, such as Windows notepad, for example) are presented with native line endings, which they can read just fine
  • Any new files, created by anything, are essentially by definition correct, produced with native line endings and (correctly) added to the repository with LF line endings (and no warnings)
  • Any files which get modified by build processes (sometimes with changes which might need to be checked in, but sometimes with no changes) are by definition correct
    • What this lets you avoid is an LF file which has been ‘modified’ by some Windows process to have exactly the same contents but now with CRLF line endings
    • I am here because npm run build in a create-react-app project on Windows DOES exactly this - it rewrites tsconfig.json, typically with no actual changes, but with Windows CRLF line endings regardless of what it started with (yes, there is a bug here in what this process does; but such bugs are widespread and almost unavoidable in practice, in a complex build set-up)

Yes, we definitely want to avoid mixed line endings in files. But I am convinced (along with the original proposer) that the most correct way to do this is to allow the standard, clean, safe core.autocrlf true (aka * text auto) behaviour by git and to have an eslint linebreak-style native variant of the rule which (automatically, nothing else needed) matches that standard, safe approach.

NB, also, using the git core.autocrlf approach but turning off the eslint rule (which seems to be the main suggestion, apart from forcing LF endings onto Windows machines, which is problematic for the types of reasons given) works, of course… as long as everything was set up right in the first-place, but it removes all verification - which eslint could otherwise provide! and surely that is part of its purpose?! - that everything was indeed set up right.

[mikebeaton]

This was the revised version, I’ve tried to keep the tone very neutral, and not-overladen with warnings, just to simply mention the issue:

---

Options

This rule has a string option:

• "unix" (default) enforces the usage of Unix line endings: \n for LF.
• "windows" enforces the usage of Windows line endings: \r\n for CRLF.
• "native" enforces OS-native linefeeds (\r\n for CRLF on Windows, \n for LF on Unix).

unix

Examples of incorrect code for this rule with the default "unix" option:

<no change>

windows

Examples of incorrect code for this rule with the "windows" option:

<no change>

native

Examples of incorrect code for this rule with the "native" option:

/*eslint linebreak-style: ["error", "native"]*/

var a = 'a', // \n     // fails on Windows
    b = 'b'; // \r\n   // fails on Unix

Examples of correct code for this rule with the “native” option:

/*eslint linebreak-style: ["error", "native"]*/

// passes on Windows
var a = 'a', // \r\n
    b = 'b'; // \r\n

/*eslint linebreak-style: ["error", "native"]*/

// passes on Unix
var a = 'a', // \n
    b = 'b'; // \n

Using this rule with version control systems

Version control systems sometimes have special behavior for linebreaks. For example, the default behavior of git on Windows systems is to convert LF linebreaks to CRLF when checking out files, but to store the linebreaks as LF when committing a change.

To make it easy for developers to contribute to your codebase from different platforms, you should configure your VCS to handle linebreaks appropriately.

If you use git, one option is to add a line to your .gitattributes file to prevent git from converting linebreaks in .js files:

*.js text eol=lf

That works with the default "unix" option for the linebreak-style rule.

Another option is to explicitly ask git to use native linebreaks for all users, regardless of their personal settings, by adding the following line to your .gitattributes file:

* text=auto

This will work with the "native" option for the linebreak-style rule. When doing this, exercise caution since the build output of your project will inherit the local linebreak style of the OS on which the build was made. Many developers consider this to be fine for development work - we leave that choice up to you - but it is not fine for release builds, and may even break the release for users on the wrong OS. If you are using a modern continuous integration approach this problem will not arise so long as you configure things so that your release builds are always made automatically, on a known image of a known OS.

[not-an-aardvark]

@MikeBeaton Sorry about the miscommunication. In this repo it’s common for people to use 👎 to simply express opposition to adding a feature, without the other connotations you suggested. I’m undecided on whether this feature would be worthwhile, but I don’t think anyone would read this and think you’re wasting peoples’ time. (Hopefully @mysticatea will be able to elaborate on his reasoning for opposing this feature request soon.)