Chore introduce husky lint staged

[koji]

Overview

introduce husky lint staged for CSS format and format with prettier.
this doesn't include anything related to type check and test since we sometimes want to ask questions other engineers and for that case, we will need to share the branch via GitHub.

close AUTH-2386

Test Plan and Hands on Testing

• checkout this branch
• change a module.css file to test this change
  ex
  protocol-designer/src/pages/Landing/landing.module.css

before
.nav_link {
  color: var(--white);
  text-decoration: none;
}


after 
.nav_link {
  text-decoration: none;
  color: var(--white);
}

• run make lint-css
  you will see a linting error

• git add and commit

git add protocol-designer/src/pages/Landing/landing.module.css
git commit -m "test"

• run make lint-css again

you won't see any css linting error

Changelog

Review requests

Risk assessment

low

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 56.29%. Comparing base (6208bf5) to head (5e2ad6e).
⚠️ Report is 18 commits behind head on edge.

Additional details and impacted files

@@             Coverage Diff             @@
##             edge   #19775       +/-   ##
===========================================
+ Coverage   25.81%   56.29%   +30.48%     
===========================================
  Files        3504     3515       +11     
  Lines      292024   297633     +5609     
  Branches    31714    39859     +8145     
===========================================
+ Hits        75380   167557    +92177     
+ Misses     216622   129802    -86820     
- Partials       22      274      +252     

Flag	Coverage Δ
protocol-designer	18.88% <ø> (+0.07%)	⬆️
step-generation	5.55% <ø> (+0.07%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.
see 1942 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[SyntaxColoring]

Interesting!

Git hooks aren't really my thing. I have my editor set up to do this kind of thing when I save the file, instead. I heavily rely on rewriting local history with git rebase, and I'm a little worried about Git hooks interfering with that (though it seems OK in my testing so far).

Overall, I'm willing to try it if other people think it'll be helpful!

[SyntaxColoring]

Heads up that this will also prevent you from committing any files with syntax errors. (Prettier will fail with an error, and that error will be treated as a signal from the Git hook to reject the commit.)

[mjhuff]

I'm pretty on the fence with this one.

I'm all for failing CI if we have a commit that doesn't confirm to some set linting rules, but I think there are a couple of potential pitfalls we open ourselves up to when we do auto-formatting via github hooks:

1. Rebase issues as @SyntaxColoring mentioned. I do a lot of this myself and would not like a git hook to impede my workflow personally.
2. It's unexpected behavior to an extent. When committing code, it's nice to know that we write is exactly what is committed for sanity reasons.
3. We already have prettierrc.js regex rules for CSS files. This hook then is either somewhat redundant or at worst, we have two competing CSS formatting rule sets.
4. Although it's highly unlikely, I could see some sort of weird instance in which some sort of CSS shadowing that causes correct behavior locally causes some sort of bug on CI that is hard to catch for the reasons stated in #2.

All that said, if people are open to trying it, I am as well. I wouldn't mind discussing this further in the next FE meeting, if we'd rather do that!

[mjhuff]

Suggested change

	"lint-staged": "^16.2.3",
	"lint-staged": "16.2.3",

[sfoster1]

if you end up running into it when rebasing you can use git commit --no-verify

[sfoster1]

I'm neutral on this one (like @mjhuff , very positive on having it in CI of course) because it's nice but it does make commits slower, it makes commits feel more formal when they don't have to be, and the rebase thing might be annoying.

[sfoster1]

okay, i'm okay with this, but we need to really resist adding more stuff to this it could get really slow