Adding husky for yarn lint-fix

[RONAK-AI647]

Description

A PR that runs yarn run lint-fix with appropriate arguments to ensure it lints only staged files.

Issue addressed

Closes #830

Addresses #*PR# 880

Before/after screenshots

Changelog

• Description: Adding husky for perfecting linting for staged files.
• Products impact: new API
• Addresses: issue#830
• Components: no
• Impacts a11y: yes
• Guidance: na

Steps to test

1. Step 1
2. Step 2
3. ...

(optional) Implementation notes

At a high level, how did you implement this?

Does this introduce any tech-debt items?

Testing checklist

• Contributor has fully tested the PR manually
• If there are any front-end changes, before/after screenshots are included
• Critical and brittle code paths are covered by unit tests
• The change is described in the changelog section above

Reviewer guidance

• Is the code clean and well-commented?
• Are there tests for this change?
• Are all UI components LTR and RTL compliant (if applicable)?
• Add other things to check for here

Comments

[EshaanAgg]

Hi! I just wanted to drop a small recommendation as I was passing by: As someone who has previously worked with husky in other large codebases, I often do appreciate if the developer documentation explicitly mentions that they are using husky to specify exactly which scripts are being run as pre-commit hooks, and how can I skip git hooks if I want to.

(The reason for that is often when I'm working on large changes, I like to make tiny commits of my progress, if in case I ever want to revert to them. Since these commits are very minor and not the final products, I often don't want to spend time waiting for the CI/CD to pass, especially checks like linting and formatting. So being made aware of it when I install the project, and a small how to on how to skip them goes a long way IMO!).

[nucleogenesis]

I definitely like the idea overall (and across products) of having a tool for solely running linting on staged files.

However, I'm not sure about adding a .husky/pre-commit config file. As @EshaanAgg mentioned, it's something that would best be documented and we'd want to be sure there is an easy way to skip the hooks as needed.

We don't have pre-commit in Kolibri Design System, though, which is how we've typically handled such hooks.

This all said, looking now at Husky for the first time, it does seems reasonably promising. Interested in thoughts from @AlexVelezLl @MisRob @rtibbles

[nucleogenesis]

@EshaanAgg 's note about how Husky handles skipping hooks w/ an env var gets me wondering if they'll also be skipped during pre-commit when using the git commit -n flag.

[RONAK-AI647]

A warm hello to everyone!!! I had a couple of thoughts , could not type them down on time , apologies!!!

The purpose I opened this PR was to overcome linting issues and enhance efficiency and code quality. My research about husky says , it helps in automation code linting before commits and thus does not let bad code enter the repository.

What @EshaanAgg said is to update the documentation to:

1. mention what husky is being used ( to run pre commit hooks) and to provide instructions in how to skip Git hooks when committing.

2)List the specific scripts that Husky runs (example: yarn lint-fix)

[RONAK-AI647]

@EshaanAgg 's note about how Husky handles skipping hooks w/ an env var gets me wondering if they'll also be skipped during pre-commit when using the git commit -n flag.

@nucleogenesis Actually there are certain environment variables present like:

1. git commit -n ( this skips all Git hooks{ pre-commit, commits-msg ,pre-push})

2)Husky_skip_hooks=1(Only affects Husky managed hooks{if any}).

[RONAK-AI647]

I definitely like the idea overall (and across products) of having a tool for solely running linting on staged files.

However, I'm not sure about adding a .husky/pre-commit config file. As @EshaanAgg mentioned, it's something that would best be documented and we'd want to be sure there is an easy way to skip the hooks as needed.

We don't have pre-commit in Kolibri Design System, though, which is how we've typically handled such hooks.

This all said, looking now at Husky for the first time, it does seems reasonably promising. Interested in thoughts from @AlexVelezLl @MisRob @rtibbles

Would you prefer:

1)Enforcing Husky via .husky/pre-commit, but documenting how to skip it?
2)Not enforcing it but documenting how to set it up optionally for those who want it?

I’m happy to update the PR based on what works best for the team. Let me know your thoughts!

[nucleogenesis]

Thanks for the replies @RONAK-AI647

I'm thinking that using husky here would be a nice improvements. I think that enforcing & documenting how to skip it would be the way to go as it is how our Python pre-commit hooks run in our other projects.

I'll await additional discussion from the team before committing to a decision, so I'll mention this PR in Slack.

[nucleogenesis]

@marcellamaki helpfully pointed out that there has already been discussion about husky, so my hesitancy to add it is gone :)

I think that once the conflicts are resolved, this is ready to go