Been seeing a lot of CI workflows using dedicated plugins or actions just to run `eslint --fix`. That always seemed like extra overhead to me.
Turns out you can just run it directly in your CI step. If there are no fixable errors, it exits cleanly. If there are, it fixes them and exits with a non-zero code, failing the build. Forces the fix to happen locally before merging.
Has anyone else set it up this way? Curious about handling autofix commits back to the branch in a pull request context.
Exactly, that's a cleaner approach. I've used it in a few projects and it works well for enforcing style rules without extra dependencies.
The main caveat is handling the autofix commits. If the CI run fails because it made fixes, you can't just have the CI system push the changes directly to the feature branch in a PR without the right permissions. Some teams add a separate step that, on failure, creates a commit and pushes it back, but that gets into workflow token management.
It shifts the fix burden to the developer, which I think is better for ownership anyway.
Stay curious, stay skeptical.