chore: remove duplicate prettier.config.js settings from .eslintrc.json

[DoctorDerek]

✅ chore: remove duplicate prettier.config.js settings from .eslintrc.json
✅ manually tested with visual inspection in VS Code and by running npx eslint --fix . as a way of fixing Prettier errors

Good news everyone!

Turns out you can ask ESLint to read Prettier's configuration file, and the eslint-prettier plugin will process it correctly.

Unfortunately, it doesn't work right the other way -- VSCode's Prettier extension won't pull the settings out of the ESLint config.

The .editorconfig file is still needed for fixing line endings to LF on save on Windows and for specifying utf-8.

Still, "prettier/prettier": ["error"] is a lot cleaner in .eslintrc.json than the copy-paste that was in there before! 😁

[sachinraja]

Why not switch to only prettier (no eslint-plugin-prettier)? eslint-config-prettier will handle conflicting rules and you don't have to see red lines every time you type in your editor. This would require running prettier outside eslint though, which is easily done with lint-staged and/or the prettier extension for your editor. I believe this would also allow for the removal of .editorconfig.

[DoctorDerek]

Hey @sachinraja thanks for your comment. Do you happen to develop on Windows? I'm not sure exactly what you mean, as this is the .eslintrc.json file that I see:

tailwindcss/.eslintrc.json

Lines 1 to 17 in c17366a

	{
	"env": {
	"jest": true
	},
	"parserOptions": {
	"ecmaVersion": 2020,
	"sourceType": "module"
	},
	"extends": ["prettier"],
	"plugins": ["prettier"],
	"rules": {
	"camelcase": ["error", { "allow": ["^unstable_"] }],
	"no-unused-vars": [2, { "args": "all", "argsIgnorePattern": "^_" }],
	"no-warning-comments": 0,
	"prettier/prettier": "error"
	}
	}

The error I think you may be referring to -- Windows developers seeing errors on every line because of CRLF line endings -- happens because ESLint forces "LF" line endings according to the Prettier rule set, even on Windows, so there's no workaround. At least there isn't as long as the ESLint config file is set to "error" (or "warn") on "prettier/prettier."

Anyway, that conversation is pretty much completely off-topic for this PR (#5087); see PR #3760 for a discussion of the line-ending problems and rationale for a .gitattributes file. This PR #5087 is a simple chore: refactor that does not change any behaviors, it just removes the unnecessarily-duplicated code that I added in PR #3713.

Regarding EditorConfig

tl;dr .editorconfig seems redundant but it differs from Prettier in that:

• EditorConfig specifies utf-8 (which is the VS Code default, but not the default for some other applications)
• EditorConfig forces LF line endings on save of a CRLF file, while the Prettier extension for VS Code does not

You're right that .editorconfig specifies LF line endings (though Prettier does as well). It also specifies utf-8, which I believe is the one. As best as I can tell, people include .editorconfig because while using it, you can have Prettier-like behavior by using EditorConfig without actually using Prettier.

In my experience the only difference is that the Prettier VS Code extension will not force-save CRLF line ending files (pulled down from GitHub) using the specified LF line ending, but the EditorConfig VS Code extension will do so.

That means that when I'm working on Windows in a repository with both .editorconfig and prettier.config.js specifying LF endings, but without a .gitattributes file that requires LF endings locally, I can hit Save in VS Code and flip the line endings to the correct one.

Otherwise, the only way to fix the line endings in the file is to manually toggle them in VS Code or run npx eslint --fix . from the command line (or probably npx prettier --write ., though I've never tried that specifically for line endings).

[sachinraja]

Sorry, I don't think I was clear in what I was suggesting. You can use prettier by itself (outside of eslint). I suggested doing this and automatically running prettier before commits. Since it would automatically run before commits, a .editorconfig file (or at least most of its options) would not be needed.

[DoctorDerek]

Hey Sachin, Sorry, I still don't understand what you're getting at. Why would I ever want to not run Prettier inside my development environment (VS Code extension)? And I think you misunderstand that I'm advocating for `.editorconfig` -- it simply has the behavior it has. I never used it until I found it in open source repositories I wanted to contribute to. If you're asking "Why the **** would you want to error on Prettier errors given that you can use pre-commit hooks to enforce Prettier to run, with a command like `lint-staged`" -- well, yeah, I'm with you there. Erroring on "prettier/prettier" doesn't make any sense to me, but it was the pre-existing condition for the @tailwindLabs/tailwindcss repository. It's a popular approach and is used by many repositories, including @timlrx/tailwind-nextjs-starter-blog and @alan2207/bulletproof-react as two quick examples I've contributed to lately. Regarding this current PR I submitted, though, I'm not sure what the discussion you're trying to have is. Are you suggesting to simply remove the `prettier/prettier` rule from `.eslintrc.json` and then remove `.editorrconfig` as well instead of accepting this PR? I mean, that's probably a better solution as long as the pre-commit hooks are in place, but it's also not at all the point of this particular PR. This PR was simply to reduce code duplication. Thanks for having the discussion with me 😀

[sachinraja]

Are you suggesting to simply remove
the prettier/prettier rule from .eslintrc.json and then remove
.editorrconfig as well instead of accepting this PR?

Yes, that is exactly what I'm suggesting. I realize that it isn't the point of this PR, but it seems the most fitting place to have this discussion. Thanks for taking the time to work on proper formatting!

[DoctorDerek]

You bet. That sounds good to me if the precommit hooks are in place already. Best regards, Derek Derek R. Austin, PT, DPT, MS, BCTMB, LMT, CSCS Read my blog on Medium: ***@***.*** Join me on LinkedIn: https://www.linkedin.com/in/derek-austin/

…

On Tue, Jul 27, 2021, 8:13 PM Sachin Raja ***@***.***> wrote: Are you suggesting to simply remove the prettier/prettier rule from .eslintrc.json and then remove .editorrconfig as well instead of accepting this PR? Yes, that is exactly what I'm suggesting. I realize that it isn't the point of this PR, but it seems the most fitting place to have this discussion. Thanks for taking the time to work on proper formatting! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#5087 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFZ3D6VBQXDKZMJZBSH4T3TZ5KTTANCNFSM5BBAOMDQ> .

[RobinMalfait]

Hey! Thank you for your PR!
Much appreciated! 🙏