Staged Linting and Formatting with Git Hooks

[nazarhussain]

Our team has recently adopted Biome as our primary linting and formatting tool. Biome has proven to be extremely fast and efficient, yet we are still noticing unformatted or incorrectly linted code slipping through, only to be caught during CI. This introduces friction later in the development lifecycle, requiring additional cycles to fix what could have been automatically handled earlier.

Problem

• Code that does not adhere to our formatting and linting rules is being committed.
• CI failures due to linting issues slow down merge processes.
• Inconsistencies in formatting can reduce code readability and make reviews harder.

Past Concerns

Previously, there was hesitation to implement git hooks using tools like Husky due to concerns about developer experience (DX) being blocked by slow linting processes.

Why Now

With the introduction of Biome, which offers ultra-fast linting and formatting, the previous concerns about speed and DX are no longer relevant. Biome performs linting and formatting in milliseconds, making pre-commit hooks nearly unnoticeable to developers.

Proposal

1. Integrate Husky into our repository to enable Git hooks.
2. Use lint-staged to run Biome only on staged files:

• Ensures that only files being committed are linted/formatted.
• Keeps hook execution time fast and focused.

3. Git hook based workflow

• Pre-commit: Run biome check and biome format on staged files.
• If Biome fixes issues, they are auto-applied before commit.
• If unfixable issues remain, the commit is blocked with clear messages.

Benefits

• Enforces consistent code quality before code hits CI.
• Reduces CI failures and shortens feedback loops.
• Improves code readability and simplifies code review.
• Minimal to no impact on DX due to Biome's speed.
• Git hooks ensure the checks are automated and consistent across all contributors.

Next Steps

• Trial this setup on a branch and evaluate developer experience.
• If successful, merge into main with team consensus.

---

Please share your opinion for adopting or not-adopting above mentioned solution.

[matthewkeil]

Not sure I agree with this. About the only thing i would be open to would be lint before push but I def dont link lint on stage or lint on commit.

[nflaig]

please no git hooks, git commit should do one thing, and that is to commit my code

[nflaig]

for anyone that wants this behavior, it's possible to add an alias or local pre-commit hook

[wemeetagain]

My vote is in favor of local pre-commit hook but no enforced hooks for everyone.

Rationale being as long as ci runs all tests and lints we don't need to enforce a hook on everyone.

[nazarhussain]

@wemeetagain Yes, was no intention for enforcing these. It's upto individual to have it enabled on workspace level or globally as user.

Rationale being as long as ci runs all tests and lints we don't need to enforce a hook on everyone.

The CI and Hooks works hands-in-hands, not replacing each other. CI on cloud environment which is usually slow for developer feedback. So if we can spend less than a second on developer machine to avoid a minute on CI feedback cycle that will make usual workflows faster.

In my personal experience, it happens to me multiple times that I opened/updated PR and later got notified by CI about lint errors and have to fix and commit again, this can be avoided as the linting time now is very fast, on staged files usually few mili-sceonds.

[nflaig]

• chore: add organize imports to VS Code settings #7670 should address most of the lint issues we observe

[nazarhussain]

IDEs are individuals contributor's choice, e.g. I am not been using VS Code lately for about a month. And similarly optional linting hooks are also individual's choice to enable or not.