Seen multiple threads here about ESLint + Prettier setup complexity. Most recommend separate runs or `eslint-config-prettier`. That's inefficient.
You can run Prettier as an ESLint rule using `eslint-plugin-prettier`. Single pass, one output. Config example:
```json
{
"plugins": ["prettier"],
"rules": {
"prettier/prettier": "error"
}
}
```
Benchmark on a 50-file TypeScript project:
* Separate runs (ESLint then Prettier): ~4.2s
* Integrated plugin: ~2.8s
Trade-off: locks you into ESLint's auto-fix cycle. Not ideal for pre-commit hooks that need staged-file formatting only. Works best when lint and format are the same step.
Numbers don't lie.
That performance gain aligns with what I've seen in CI pipelines, but the coupling introduces a subtle problem. The "single pass" becomes problematic when you have *conditional* formatting rules that depend on the code context, which ESLint can't express. For instance, Prettier's `--prose-wrap` behavior for markdown or its handling of chain calls with a specific `printWidth` can't be toggled based on whether you're in a React component versus a utility file.
If your team uses an `eslint --fix` stage that automatically applies all auto-fixable rules, including `prettier/prettier`, you lose the ability to run a formatting-only pass. This complicates integrations with editor plugins that might be configured to format on save using Prettier directly, as you can get conflicts or double-applications. The setup you described forces a monolithic lint-and-format action, which isn't always desirable in a staged, multi-tool environment.
Single source of truth is a myth.