Consider start using the pre-commit framework

[leandro-lucarella-frequenz]

pre-commit is a framework for managing and maintaining multi-language pre-commit hooks.

I think developers could benefit from getting some safe-nets easily installed so common problems are detected early (at commit-time) instead of waiting for a PR CI to run for example.

Being a common framework we could benefit from and contribute to a wider community.

Copying the introduction for convenience:

Git hook scripts are useful for identifying simple issues before submission to code review. We run our hooks on every commit to automatically point out issues in code such as missing semicolons, trailing whitespace, and debug statements. By pointing these issues out before code review, this allows a code reviewer to focus on the architecture of a change while not wasting time with trivial style nitpicks.

As we created more libraries and projects we recognized that sharing our pre-commit hooks across projects is painful. We copied and pasted unwieldy bash scripts from project to project and had to manually change the hooks to work for different project structures.

We believe that you should always use the best industry standard linters. Some of the best linters are written in languages that you do not use in your project or have installed on your machine. For example scss-lint is a linter for SCSS written in Ruby. If you’re writing a project in node you should be able to use scss-lint as a pre-commit hook without adding a Gemfile to your project or understanding how to get scss-lint installed.

We built pre-commit to solve our hook issues. It is a multi-language package manager for pre-commit hooks. You specify a list of hooks you want and pre-commit manages the installation and execution of any hook written in any language before every commit. pre-commit is specifically designed to not require root access. If one of your developers doesn’t have node installed but modifies a JavaScript file, pre-commit automatically handles downloading and building node to run eslint without root.

[Marenz]

Well, it becomes a bit of "In the Editor" vs "At commit time". The earlier the better of course. The intro talks about linters here which I already have in my editor, so at least that part wouldn't help me.

[leandro-lucarella-frequenz]

Yeah, I see your point and is partly why I'm not 100% sure about this and I just opened a discussion. I think the problem with editor checks is it is hard to make sure everybody uses the same, as people like to use different editors and different plugins, while with git, unless you are using some obscure implementation of git that doesn't support hooks (I'm sure there is one out there :D), everybody will get the checks exactly as we want them to be.

This will also be optional, so people that have their editor properly configured can just ignore it. At the end, the final check will be the CI. I agree if your editor matches the checks the CI does, there is no need for the commit hook and it will just slow things down, but maybe there is a group of people that don't like fancy editors but still want to make sure they send linted PRs.

The other thing that makes me wonder is I've seen many projects using this, so it makes me think there might be something else to it we are missing :P

[Marenz]

Well, it certainly provides a good common ground basis for everyone and thus can take work off the CI