+1 having the local linting commands explained in the developer documentation seems like an easy way for new contributers to check the linting. Then jenkins can run linting to prevent any unlinted code from merging.
1 Like
I disagree - I don’t think this is an issue of documentation, we already have some documentation about this. It’s an issue of making it easier for new contributors to understand what is wrong in their code, and I think inline comments from the hound (or any other tool) are the best way to achieve this. long time contributors who don’t want to be bugged about linting can just add a git hook to run it automatically or set up their editor to fix it on the fly.
Like @Gwmngilfen I don’t contribute to core that much, but what I do like about Hound are the inline comments that I probably would have placed as well if I was doing a review. AFAIK it’s now using the review API which means it doesn’t spam your inbox as much as it used to. It’s true that as a human you’d probably say ‘just run rubocop yourself’ rather than comment on every single line to keep the review smaller.
However, I do see the arguments of control. We now see it because of this plugin, but we had another in the eslint preset IIRC. To me running on a service we control using the proper APIs would be a benefit.
https://christoph.luppri.ch/articles/code-quality/how-to-automatically-review-your-prs-for-style-violations-with-pronto-and-rubocop/ looks like something that could provide all the things, but of course this would need testing with plugins and non-standard configurations…