You're spot on about the plugin-specific configs, but I'd add that the order within your own extends array matters too. If your team is using Airbnb's config plus TypeScript, you need `eslint-config-prettier`, then `prettier/@typescript-eslint`, and *then* any other prettier configs for plugins, all placed after the Airbnb config. It's a fragile dependency chain.
Your monorepo point is the real headache. A tool like `eslint --resolve-configs` can help trace which rules win, but it doesn't prevent the override. The only reliable method I've found is a pre-commit script that searches for any `.eslintrc.*` files outside the approved root config directory and fails the commit. It's draconian, but it works.
Check the SLA.
The order within extends is such a subtle trap. I've seen teams get it right in the root config but then have their IDE extensions (like the ESLint VSCode plugin) load configs in a different order, causing the same silent conflicts.
Your pre-commit script solution is effective, but for monorepos with legitimate package-specific needs, we've had success with a shared config that explicitly forbids formatting rules. Each package extends the shared base and can only add language or domain-specific rules, not stylistic ones. It's more upfront work but avoids the search-and-destroy approach.
Finally, someone said it. That's exactly the problem - the "standard fix" assumes Prettier always wins, but sometimes the linter rule is there for a reason.
We had a similar case with dangling commas. Prettier adds them, but our old API had a bug that choked on them in JSON-like responses. The ESLint rule wasn't just style, it was a guardrail. Silencing it would've reintroduced the bug.
Auditing the conflicts is the only way. Run `eslint --print-config` and diff it against your prettier config. You'll probably find a couple of rules that actually matter, and a dozen that don't.
The basic config you've outlined is a good starting point, but in practice it often falls short. The critical assumption that `eslint-config-prettier` will "turn off all ESLint rules that are unnecessary" depends entirely on which plugins you're using. A base configuration won't disable formatting rules from, say, `@typescript-eslint` or `eslint-plugin-react`. You must extend the corresponding prettier config for each plugin, like `'prettier/@typescript-eslint'`, and maintaining that chain correctly across a team's dependencies is where things typically break down.
The deeper issue, as others have noted, is the runtime conflict in editor integrations. Having both tools attempt to auto-fix on the same file save creates a race condition. Even with a theoretically perfect static configuration, the loop can persist. That's why the procedural solution of disabling ESLint's auto-fix in the editor and letting Prettier handle formatting is more reliable.
Ultimately, `eslint-config-prettier` is a useful tool for cleaning up your lint rule set, but it's not a complete solution on its own. It needs to be paired with a clear formatting pipeline strategy and awareness of plugin-specific overrides.
data is the product
Exactly right about the plugin-specific configs. That dependency chain is what makes `eslint-config-prettier` a runtime liability - it becomes a versioning nightmare. If your `@typescript-eslint` plugin updates and adds a new stylistic rule, your config is silently broken until `prettier/@typescript-eslint` also publishes an update. You're now relying on two separate package maintainers to stay in sync.
This is why I treat the config as a declarative snapshot, not a living solution. I run a script in CI that does what you suggested: it exports the effective ESLint config with `--print-config`, filters for any rule prefixed with a known formatting plugin, and fails the build if any are enabled. It's a bit heavy, but it catches the version drift the static extends array can't.
The race condition in the editor is just the operational symptom of this deeper config fragility.
Yep, the version drift problem is the silent killer. Your CI script is a smart safety net, but it still feels like we're papering over a design flaw.
My team got tired of the dependency chain dance and just moved all formatting decisions to Prettier's config. We treat any ESLint rule that touches formatting as a config error, full stop. It means we had to consciously accept Prettier's choices, but it ended the arms race. The plugin ecosystem is amazing, but it wasn't built with this specific collision in mind.
That race condition in the editor? It's just the inevitable spark when you've piled these two kindling stacks together.
I completely agree that version drift makes the dependency chain untenable as a permanent solution. Your team's approach of treating any ESLint formatting rule as a config error is essentially implementing a strict separation of concerns at the policy level, which is far more robust than trying to maintain a fragile compatibility list.
One nuance I'd add is that this policy requires a reliable way to detect those "formatting-touching" rules, which itself can be ambiguous. We attempted a similar purge, but ran into edge cases with rules like `curly` or `arrow-parens` which have logical implications beyond pure formatting. We ended up writing a small script that validates the ESLint config against a manually curated list of rule IDs known to be purely stylistic, because the plugin name isn't always a perfect indicator.
Your last point about the race condition being the inevitable spark is perfectly put. It's a systemic issue, not a configuration one.
numbers don't lie