[DRAFT] 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]

@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.

[MisRob]

Hi @RONAK-AI647, are you planning to come back to this? The only thing that remains to be resolved are conflicts.

[RONAK-AI647]

Yes @MisRob , I need sometime , I faced an accident and my partial body is burnt . So ,Noone is letting me sit with my laptop....

[MisRob]

Oh I'm so sorry to hear that @RONAK-AI647. Sending wishes for healing. Don't be worry about this at all.

[RONAK-AI647]

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!).

hi @MisRob ,just wanted to ask if any update in the documentation [part is also needed ???? referring to this conversation

[MisRob]

I don't think it's blocking, but rather optional suggestion @RONAK-AI647, but will let you and @nucleogenesis to coordinate on when to merge this work.

[RONAK-AI647]

ok @MisRob

[nucleogenesis]

@RONAK-AI647 I think this is good to go once the merge conflict is resolved

[RONAK-AI647]

ok I will check whats wrong and make the change @nucleogenesis

[MisRob]

Hi @RONAK-AI647, I think it'd be good to wrap this work. Re-running yarn lint should resolve the conflicts, I assume. Let us know if you needed any assistance or if you cannot get to resolve this.

[RONAK-AI647]

@MisRob , check this error , files present but never used when i run yarn lint , so do i remove these files manually , I don;t think that will be right . Majorly two folders have this error named , lib/ docs/pages/usekshow.vue

If i put this files in eslintignore , it will pass the yarn lint but certainly the percy checks here will fail .

[MisRob]

@RONAK-AI647 before you re-lint, can you merge the latest develop to your branch?

[RONAK-AI647]

@MisRob i have already done that , yet the lint is creating this error . I thought may be this branch has overgone through some serious changes which might bring errors . so tried making a new branch , did yarn install , and then yarn lint , then also this lint error occured , with ,my new branch also ... ?? any possible reason of such errors ....<...... this found , but never used >

[MisRob]

@RONAK-AI647 thanks for giving it a try. I realize these conflicts are accumulating because we postponed this PR. Let me take it from here - I will push to your branch so please don't do any further changes. Thanks for this work!

[MisRob]

Can you re-review @nucleogenesis?

[MisRob]

Thank you @nucleogenesis, I wonder if I caused this with my rebase, or if it was the case before. By any chance, do you recall if it worked for you during the previous review?

[MisRob]

Looks we won't merge this any time soon for reasons above - converting to draft in case it's handy at some point

[RONAK-AI647]

While working on this PR, I also encountered a problem where the Husky pre-commit hook runs yarn lint-fix, shows the expected output (indicating that it fixed the lint issues), but the fix isn't applied to the commit. May be I see the root cause is the kolibri-format tool (used in yarn lint -w) returns exit code 1 even when it successfully rewrites files. This causes lint-staged to treat it as a failure.

Should we turn "lint-fix": "yarn lint -w" to "lint-fix": "yarn lint -w || true"

[MisRob]

@RONAK-AI647 thanks for looking into it! We're having another discussion in parallel with @rtibbles about perhaps having to eventually use pre-commit after all even though we initially recommended Husky. Because of some new non-JavaScript functionality we're adding to KDS we will need to lint. We'll follow-up as soon as we know more.

[RONAK-AI647]

@MisRob Thanks for the response. Casually asking ,I don't find any help wanted issue , it's long not contributed to LE . Will you list some in upcoming days ??

[MisRob]

Good to hear that @RONAK-AI647! We have new contributing guidelines that contain link to free issues, most of them are from a whole new frontend project that is actually prepared specifically for community contributors. I'm currently the main coordinator and would be happy to see you there! There are currently 3 free issues, and I keep adding new ones. A previous contributor didn't finish https://github.com/learningequality/studio/issues/5082 - that may be a nice start with this project since the linked closed pull request already contains some code that could be re-used, together with my review.