Personally I like husky. It runs the tests and linting before a commit happens.

It has saved me numerous times. I also like following the conventional commit messages over fixes thing maybe.

I think it encourages good developer practices for new developers.

I use commitizen as a global tool when I create commits

We removed husky in October after feedback from multiple individuals that it was making contributing harder

#323

I personally have had to fight with husky more than once, and lost entire commit messages because I didn't include a capitalized first word in the commit message (something we actually lint to not have in the node.js repo). While I appreciate the value of something like conventional commits I don't really think it matters for a repo like nodejs.dev which is a website not a library that requires a changelog. In short I don't think we get significant value out of enforcing commit guidelines for this repo at all and instead create an additional barrier to entry to folks contributing externally. Also afaict this is not enforced if you edit on github nor do we lint for it in CI, so it is currently inconsistent at best.

Further, this was something that was removed via consensus and added back as a regression from staging being merged (prematurely might I add). If we want to add it back we should build group consensus around it being added, not have it be added due to an error.

@alexandrtovmach while removing husky was partially inspired by the yarn / npm mismatch the PR that gained consensus had a broader reasoning

#323 (comment)

Relanding husky as part of merging staging undid that consensus. If we want to bring husky back I think the proper way to do it is to remove it again and open a new PR about bringing it back. To be clear I would be planning to block that PR based on the reasoning I gave in the original PR to remove it. I do not see the value we gain in having linted commit messages for this project as we do not do change logs... it only creates friction for developers (both new and experienced)

@saulonunesdev PTAL I've updated the package-lock.json and also removed the commit lint dependencies that are no longer being used

The PR was failing npm ci due to the double Typescript dependencies so I've fixed that as part of this PR as well. Currently it is done in a single commit but can break it out into two.

@alexandrtovmach I've thought a bit about the commit linting stuff... if we really want to enforce commit linting I think it would be better to do it as a CI job and something that is fixed prior to landing, this is how we do it in node.js core. Enforcing it before pushing creates a ton of friction imho that really isn't worth it for the scope of this project.

@MylesBorins my point about keeping husky is i18n goals nodejs/i18n#283. If it's better to remove and then add again - okay, let's go!

I jumped here from nodejs/nodejs.org#3172

@alexandrtovmach protecting those folders seems like a great idea, but also something that doesn't require linting the commit messages to accomplish. Would you be open to removing your block on this PR and opening a new issue to discuss how we can accomplish this? I think it would be prudent to do it the same way across repos... so if commit linting is how we do it then I'd be more open to it... but I'm still not convinced we neet to lint the commit title + message content... which is what I originally had issue with husky around.