Hi everyone. I've been seeing a steady trickle of support requests in various channels about this, so I thought it was worth starting a dedicated thread. The core issue is when ESLint and Prettier step on each other's toes, leading to a loop where one tool "fixes" the formatting the other just applied, or you get persistent lint errors for code that Prettier has formatted.
The most common culprit is having formatting rules enabled in ESLint that Prettier is also designed to handle. Think `indent`, `quotes`, or `semi`. When both tools are active in your editor or pre-commit hook, they can fight endlessly.
If you're hitting this, the standard fix is to use the `eslint-config-prettier` package. Its sole job is to turn off all ESLint rules that are unnecessary or might conflict with Prettier. You'll add it to the `extends` array in your ESLint config, making sure it's listed *last* so it can override other configs properly.
A quick example for your `.eslintrc.js`:
```js
module.exports = {
extends: [
'eslint:recommended',
'some-other-config',
'prettier' // This goes last to disable conflicting rules
]
};
```
If you're using a framework-specific config (like `plugin:vue/recommended`), you might need the scoped version, like `prettier/vue`.
Beyond that, the setup can sometimes be tricky with shared configs or monorepos. If you've followed the steps and things still aren't playing nice, please share your configs (both ESLint and Prettier) and the specific error or behavior you're seeing. Let's get everyone's formatting pipeline running smoothly.
Keep it civil, keep it real.
Yep, `eslint-config-prettier` is the go-to. I'd just add that you really need to check your editor's settings too - sometimes the ESLint plugin there is trying to format on save *and* the Prettier plugin is also set to format on save. That creates a loop even with the config right. I usually disable the formatting capability in the ESLint extension entirely and let Prettier handle it.
cost first, then scale
Yeah, the editor plugin loop is so real! I've seen it bite our junior devs a few times. A trick that works for VSCode is to set your `editor.defaultFormatter` explicitly and then just use `editor.formatOnSave`. It stops the extensions from wrestling over control.
Also, if you use a monorepo, double-check that the config file extends are actually reaching all the nested projects. Sometimes a stray local `.eslintrc` can re-enable those formatting rules and mess up the whole setup.
Dashboards or it didn't happen.
Good start on the explanation, but that example is missing a key detail. If you're using a framework config like `eslint-config-airbnb` or `@vue/eslint-config-typescript`, you must extend `prettier` *after* those, but also potentially after `prettier/react` or `prettier/vue`. The base `prettier` config doesn't cover all plugin-specific formatting rules.
For instance, with a React TypeScript project, your extends array should look like this to be safe:
```
extends: [
'eslint:recommended',
'plugin:@typescript-eslint/recommended',
'airbnb',
'airbnb/hooks',
'plugin:react/recommended',
'prettier' // This alone is insufficient
]
```
You actually need:
```
extends: [
'eslint:recommended',
'plugin:@typescript-eslint/recommended',
'airbnb',
'airbnb/hooks',
'plugin:react/recommended',
'prettier', // Turns off core formatting rules
'prettier/react', // Turns off React plugin formatting rules
'prettier/@typescript-eslint' // Turns off TypeScript plugin formatting rules
]
```
Missing those extra configs is why people think they've fixed it but still get rule conflicts on JSX props or type annotations. The documentation for `eslint-config-prettier` lists all the available extensions, but everyone just skims it.