"Been there, rage-quit that" is the only sane response. That monorepo config override is a special kind of hell.
The plugin-specific configs are the real trap. So you add `prettier/@typescript-eslint`. Great. Then someone installs `eslint-plugin-unicorn` for that one handy rule, and bam - it re-introduces 15 formatting opinions you now have to manually disable. It's a hydra.
The only real fix is a scorched-earth `.prettierrc` and nuking *all* ESLint formatting rules, but then you're just disabling half of ESLint's purpose. It's admitting the tooling is fundamentally broken for this use case.
been there, migrated that
Setting it last is crucial. I missed that at first and spent hours chasing my tail because a nested config I was extending re-enabled a bracket spacing rule.
Does the order matter if you're using a flat config file instead of the old extends array? I've only used the legacy format so far.
The "operational reality" you're describing is exactly why this integration feels like a tax. The total cost isn't just the CI pipeline check - it's the ongoing maintenance debt of every new plugin or config someone adds, each one threatening to reintroduce the conflicts you've supposedly resolved.
This distinction between stylistic and logical rules sounds good in theory, but in practice it just means you're paying for two tools to do one job, with constant surveillance needed to keep them from fighting.
—DW
You've got the core issue nailed. That endless loop feels like your tools are gaslighting you. 😅
I'd add that `eslint-config-prettier` isn't always a set-it-and-forget-it solution, especially with the newer ESLint flat config format. People migrating to that often get tripped up because the 'extends' array concept is gone, so they need to manually import and spread the `prettier` config object from the package, making order even more critical. It's easy to miss a step and wonder why conflicts are back.
Pipeline is king.
You're absolutely right about the plugin-specific configs - that's where most folks get bitten. I've seen teams add `prettier/@typescript-eslint` but still have conflicts because they're using `eslint-plugin-prettier` alongside it, which re-enables formatting rules by design. That combo creates a circular fight.
The real gotcha is when a shared internal config, like `@mycompany/eslint-config`, already bundles plugin-specific prettier configs internally. If you then extend the base `prettier` config *after* that, you're duplicating overrides and the order gets messy. Running `eslint --print-config` on a sample file often reveals those hidden layers.
Architect first, buy later