little cubes

Combining Eslint & Prettier in VS Code

Avoiding conflicts between the extensions

I’m going to jump the gun here and give the solution first. To prevent the Prettier and ESLint VS Code plugins from conflicting with each other, add this to your settings.json file:

"eslint.codeActionsOnSave.options": {
"rules": ["*", "!prettier/prettier"]
}

eslint-plugin-prettier provide a mechanism for allowing ESLint to report bad formatting as ESLint errors (or warnings), which is great.

{
rules: {
'prettier/prettier': 'warn'
}
}

If everybody had prettier correctly set up all the time putting it in ESLint wouldn’t really be necessary, but I’ve found that just isn’t something you can rely upon in a corporate environment. So having the build break with lint errors if formatting is wrong is helpful to ensure that consistency.

The ESLint VS Code is great because it can auto-fix most of your lint problems when you save the file without you having to think about it. For example if an import isn’t used anymore it can just remove it instead you having to scroll up and do so.

It will also fix your prettier formatting issues on save.

The Prettier VS Code obviously also fixes your formatting issues for you. And it doesn’t rely on ESLint, so it works for any old file, or for projects where ESLint isn’t configured to look for prettier violations.

The trouble is that when you have both of these extensions active and formatting on save and ESLint is configured to fix prettier violations, then they will sometimes conflict and both format and end up mangling your file and making you undo and re-save and it’s irritating.

The solution (as you already saw at the beginning of this post) is to tell the ESLint VS Code extension (but not ESLint itself) to not format the prettier rule on save, but still format all the other rules.