Consensus about activating Husky on mdn/content?

[teoli2003]

I would like to hear if we have a consensus about activating Husky on mdn/content.

Here is some extra information:

• Husky, together with lint-staged, is a tool to add pre-commit hooks to your local git repository.
• Each time you type git commit (or a local tool does it), it runs the hooks.
• This is a toolchain already used by mdn/yari. If you have done PRs there, you may have noticed it running.
• Husky doesn't run when you commit from the GitHub UI.
• The only thing you'll have to do is run yarn install again, locally. (And you should do it periodically anyway)

What we will do with it:

• We will run markdownlint on the (md) files that are staged and fix the small errors you may not have seen (trailing lines, double empty lines, …). These are the same errors that the markdownlint workflows flags in the PR and that another workflow fixes daily. (All use the same config file). This will lower the noise of these workflows (that stay needed as the GitHub UI is not concerned)
• We will also run Prettier on the JSON files (and only those!): this will automatically fix errors in GroupData.json and other similar files. These errors are currently caught by the JSON lint workflow in each PR (and fairly annoying to fix!). This will reduce the noise and the (light) friction we have since its activation.

I do think this is a good step forward. It will make the Markdownlint test fails only when the GitHub UI is used, and you can forget about it when dealing with your own PRs.

Link to the PR: mdn/content#20397

Thumb-up if you agree / Thumb-down if not (and if you give reasons, I would be even happier)

[Rumyra]

Thanks @teoli2003 :)

[Josh-Cena]

I'm a minor plus on this, as in, I think other people would be happy about this, and I won't be made sadder. I'm a big fan of husky + lint-staged in general (my own project template includes them), but in the context of mdn/content, I feel like it's not hugely helpful. I often commit changes rapidly after creating the PR (because afterwards I will read the diff and make minor adjustments, and I have to be quick to get ahead of reviewers), but a pre-commit process slows it down. I may need to adjust my workflow after this change, but I feel like it doesn't add much value—once we make linting & formatting required, there's no chance of bad code leaking into the master branch anyway.

[teoli2003]

Thank you.

I often commit changes rapidly after creating the PR (because afterward I will read the diff and make minor adjustments, and I have to be quick to get ahead of reviewers), but a pre-commit process slows it down.

A change in your workflow may prevent this: both the GitHub UI and CLI allow you to mark a PR as a draft (or unmark it). That way you don't have to rush out to get ahead of reviewers :-)

[teoli2003]

It looked like we had a consensus, so we activated this!