This doesn't work because if you have ESLint set to error then (like to error on Prettier) than Windows developers will get CRLF endings with errors on every line. They'll have to "eslint . --fix" and make a fake commit to fix the problem.
text=auto can't be the solution, since it's the default...
I think your remark misses the point I was originally trying to make, which is to give developers the freedom to use whatever line ending they want to use on their development platform.
Enforcing \n via ESlint rule defies that purpose, so why did you set up your project with that .gitattributes rule?
Also why don't you just disable that line ending ESlint rule since it's safe to assume that the line endings are always correct on the platform where you check out and build your project. There is no point in checking for \n line endings using that .gitattributes setting.
I agree 100% that the ESLint line ending rule is pointless and dumb. But I find that a ton of open source projects enforce it, while few have .gitattributes files.
So instead of convincing a library to change their ESLint settings, the .gitattributes file (* text eol=lf) absolutely fixes the issue for Windows developers without other changes. For everyone else, it's just pointless.
If you are using ESLint to enforce Prettier settings, it makes sense. But it will also cause the error. You could fix it by changing the ESLint rule, because it's pointless, but it's easier to add .gitattributes instead, I think.
To put it another way, you'd never accept a contribution from a Windows contributor using Notepad in the first place, because they can't use Prettier. (OK, they could run Prettier and ESLint manually, but it's just not a realistic development environment.) So since you're already enforcing Prettier to the point of erroring on it, then you might as well force them to download the correct line endings when checking out.
This doesn't work because if you have ESLint set to error then (like to error on Prettier) than Windows developers will get CRLF endings with errors on every line. They'll have to "eslint . --fix" and make a fake commit to fix the problem.
I think your remark misses the point I was originally trying to make, which is to give developers the freedom to use whatever line ending they want to use on their development platform.
Enforcing
\nvia ESlint rule defies that purpose, so why did you set up your project with that.gitattributesrule?Also why don't you just disable that line ending ESlint rule since it's safe to assume that the line endings are always correct on the platform where you check out and build your project. There is no point in checking for
\nline endings using that.gitattributessetting.Hey Thomas! Thanks for your thoughtful reply.
I agree 100% that the ESLint line ending rule is pointless and dumb. But I find that a ton of open source projects enforce it, while few have .gitattributes files.
So instead of convincing a library to change their ESLint settings, the .gitattributes file (* text eol=lf) absolutely fixes the issue for Windows developers without other changes. For everyone else, it's just pointless.
A common ESLint configuration file errors on prettier/prettier, ala Tailwind: github.com/tailwindlabs/tailwindcs...
If you are using ESLint to enforce Prettier settings, it makes sense. But it will also cause the error. You could fix it by changing the ESLint rule, because it's pointless, but it's easier to add .gitattributes instead, I think.
To put it another way, you'd never accept a contribution from a Windows contributor using Notepad in the first place, because they can't use Prettier. (OK, they could run Prettier and ESLint manually, but it's just not a realistic development environment.) So since you're already enforcing Prettier to the point of erroring on it, then you might as well force them to download the correct line endings when checking out.
ESLint even recommends .gitattributes over changing the ESLint setting from its default eslint.org/docs/rules/linebreak-st...