Best way to handle ESLint and Prettier conflicts in a CI pipeline

Alright, let's cut through the usual optimism. You want to handle ESLint and Prettier conflicts in CI? The goal isn't just to make the errors go away; it's to make the process deterministic and stop wasting engineer cycles on formatting debates in pull requests. If your CI is constantly failing over formatting or linting, your local setup is broken, and you're using CI as a crutch. That's a workflow smell.

The core problem is a lack of a single source of truth. You see teams where Prettier is formatting code one way, ESLint's style rules are configured another way, and then the IDE plugin is applying its own on-save fixes based on God-knows-what. The fix isn't in the CI pipeline; it's in enforcing absolute consistency *before* the code ever gets to CI.

Here's the hard truth: you need to lock this down at the tooling level, and your CI job should be a final, redundant check that almost never fails. Here's how you do it.

First, kill the conflict at the root. Use `eslint-config-prettier` to turn off all ESLint rules that conflict with Prettier's formatting. Then, use `eslint-plugin-prettier` to run Prettier as an ESLint rule. This makes ESLint the single orchestrator for both code quality *and* formatting. Your `.eslintrc.js` should look something like this:

```javascript
module.exports = {
extends: [
'eslint:recommended',
'plugin:@typescript-eslint/recommended',
'prettier' // This MUST be last. It turns off conflicting rules.
],
plugins: ['prettier'],
rules: {
'prettier/prettier': 'error' // Reports formatting as ESLint errors
},
parserOptions: {
ecmaVersion: 'latest',
sourceType: 'module'
}
};
```

Second, your local editor must be incapable of producing non-compliant code. This means:
* The ESLint and Prettier VSCode (or JetBrains) extensions are installed.
* Your workspace `.vscode/settings.json` enforces formatting on save *using the ESLint fix*:
```json
{
"editor.codeActionsOnSave": {
"source.fixAll.eslint": "explicit"
},
"editor.formatOnSave": false, // Let ESLint handle it via prettier plugin
"eslint.validate": ["javascript", "typescript", "vue"]
}
```
* You have a `lint-staged` configuration in your project to run the same linter on pre-commit hooks:
```json
// package.json
"lint-staged": {
"*.{js,ts,jsx,tsx}": "eslint --fix --max-warnings=0"
}
```

Now, for your CI pipeline. Its job is verification, not fixing. It should run the exact same command your developers run locally and in pre-commit. The script must be idempotent. If CI fails, it means a developer bypassed the local tooling. The CI step should be simple, fast, and a hard gate.

```yaml
# Example GitHub Actions step
- name: Lint and Format Check
run: |
npm run lint:ci
```
Where your `package.json` script is:
```json
"scripts": {
"lint": "eslint --fix .",
"lint:ci": "eslint --max-warnings=0 ."
}
```
Note the `--max-warnings=0`. Zero tolerance. No warnings. This stops the inevitable "it's just a warning" slide.

The migration pain points you'll hit:
* Legacy codebases will light up like a Christmas tree. You need a one-time, project-wide `eslint --fix` applied, and then lock it in.
* Developers will complain about editor setup. Solution: document it once, script it, and make it part of the onboarding. No exceptions.
* If you have multiple languages or project types, you need a monorepo-aware ESLint setup or duplicated configs. Consistency is key.

Bottom line: Stop trying to resolve conflicts in CI. Engineer the conflict out of existence by making ESLint, via the Prettier plugin, the undisputed authority. CI is just the bouncer at the door, checking the ticket. If the ticket is fake, the problem happened long before they got in line.

---