Question

I am debating two strategies for setting up a linter for my team's github repository. Is strategy #1 standard practice, or not?

#1 - Set up a pre-commit hook that runs the linter

#2 - My team will manually run the linter on external Pull Requests

  • #1 puts more responsibility on the contributor because they need to install and run our linter. An argument against this is that we may get more external contributors if they don't need to worry about this step. IE - Make it easy, and we will get more contributors.

  • #2 relies on my team to pull, branch, lint, push, and then make a new PR for every external contribution. While it's easier for the submitter, I think this task is best suited for automation. IE - the contributor should submit linted code, which we test and accept/reject with our CI infrastructure.

I prefer #1. Is this workflow more typical than #2, and why?

Was it helpful?

Solution

Because people (definitly includes me) have the tendency to focus on "delivering the feature", they tend to sometimes forget the quality assurance steps. Therefor i add the linting always to the commit process, to ensure that only code is commited that follow the rules.

I would also add the linting into the CI pipeline. As a last line of defense, just to be sure.

If you do not have a CI pipeline, then i would definitly manually lint all incoming PR´s, just to be on the safe side, because i can´t know if the pre-commit hook was active and executed on the dev´s machine when he/she commited the code.

Licensed under: CC-BY-SA with attribution
scroll top