Lefthook vs Husky: git hooks tool comparison

Yes — git hooks can always be bypassed with git commit --no-verify or git push --no-verify. This is by design — hooks should assist development but not block emergency situations where a developer needs to commit quickly. The correct response is not to make hooks unbypassable (which is impossible and counterproductive) but to ensure quality gates exist beyond hooks: CI must enforce all quality requirements as non-bypassable checks on pull requests. Hooks provide fast local feedback in the common case; CI catches anything that slips through. Track --no-verify usage if it becomes chronic — if developers are regularly bypassing hooks, it indicates the hooks are too slow or too noisy, which is a hook configuration problem to solve rather than an enforcement problem to escalate.

Large monorepos require two optimisations for practical git hook performance: staged file filtering (run checks only on files changed in the commit, not the full codebase) and workspace-aware execution (run checks in the relevant workspace packages, not all packages). Lefthook's native glob filtering and workspace support handle both natively. Husky requires lint-staged for staged file filtering and custom scripting for workspace-aware execution. Both approaches should use concurrent execution for independent checks. The performance target for pre-commit hooks in large monorepos is under 3 seconds — developers notice anything longer and start using --no-verify. If checks take longer, split between pre-commit (fast: lint, format) and pre-push (slower: type check, fast unit tests), and push comprehensive tests fully to CI.

Only if it's fast enough not to disrupt commit flow — typically under 3–5 seconds. Full TypeScript type checking on a large codebase can take 30–60 seconds, making pre-commit hooks impractical. Solutions: use tsc --noEmit with incremental compilation (significantly faster on subsequent runs); limit type checking to changed packages in a monorepo; use ts-prune or similar for partial type checking on staged files only; or move type checking to the pre-push hook rather than pre-commit (acceptable tradeoff between speed and feedback timing). For teams where type errors are frequently committed, pre-push type checking is a good middle ground — slower feedback than pre-commit but prevents type errors from reaching the remote without CI review. ESLint with typescript-eslint provides fast type-aware linting on staged files as an alternative to full tsc, catching the most common type errors with lower performance overhead.

Both Husky and Lefthook commit their configuration to the repository, so configuration sharing is automatic once a developer clones and installs. The critical step is ensuring hooks are installed automatically during npm install — both tools support this via the prepare script in package.json, which runs automatically after npm install. For teams where developers may not run npm install after cloning (common in polyglot projects), Lefthook's binary installation (brew, binary download) ensures hooks work without requiring npm install at all. For CI environments, hooks are typically bypassed intentionally — CI should run the same checks via direct command execution rather than via git hooks, both for reliability and to avoid the overhead of git hook management in CI containers.

Pre-commit (must complete in under 3–5 seconds): staged file linting (ESLint, Biome, language-specific linters on changed files only); code formatting application (Prettier, gofmt — apply rather than check, so the commit includes formatted code); simple file checks (no debug statements, no large binary files, conventional commit message format). Pre-push (can take up to 30 seconds): TypeScript type checking (incremental); fast unit tests that cover changed code; branch naming convention checks. Reserved for CI only (too slow for hooks): full test suite, integration tests, security scanning (SAST/DAST), dependency vulnerability scanning, build verification. This distribution keeps local hooks fast and focused on what developers care about immediately, while ensuring comprehensive validation happens before code merges.

Yes — Lefthook distributes pre-compiled binaries for Windows (both AMD64 and ARM64), and the YAML configuration works identically across Linux, macOS, and Windows. The main consideration is that run commands need to be cross-platform — if your hooks invoke bash scripts (common in Husky configurations), you'll need either PowerShell/cmd equivalents for Windows developers or WSL2 for consistent Unix-like execution. Most Node.js and Go CLI tools invoked by hooks (ESLint, Prettier, golangci-lint) are cross-platform themselves, so the hook commands can be written portably. Teams with mixed developer OS environments (common in enterprise) should test hook execution on all target platforms during initial configuration — shell-specific syntax in run commands is the most common cross-platform incompatibility.

Lefthook hooks run in the shell environment, so standard environment variable access works normally — hooks can read environment variables set in the shell or defined in .env files (if loaded by the shell profile). For hooks that need to access secrets (API keys for external services, tokens for private package registries), use the shell's standard secret management mechanisms: environment variables set securely in the developer's shell profile (not .env files committed to the repository), or operating system keychain integration. Hooks that require secrets for their function — rare but not unheard of (pre-push hooks that call API endpoints for validation) — should be designed to gracefully skip their validation when the required credentials are absent, rather than blocking the commit for developers who don't have those credentials (e.g., external contributors or developers working on unrelated parts of the codebase).

Husky remains the right choice in several scenarios: pure JavaScript/TypeScript projects where Node.js is universally present and hook performance is acceptable (under 5 seconds); teams where the cognitive overhead of introducing a new tool outweighs the performance benefit; projects with complex existing lint-staged configurations that would require significant effort to port; and organisations with standardised tooling policies that include Husky. Lefthook's advantages (performance, cross-language support, native parallel execution, single config file) are most valuable in polyglot projects, large monorepos with slow hooks, and teams actively investing in developer experience optimisation. The migration effort is low, so the decision is more about whether the performance improvement is large enough to justify the change in the specific project context — not a fundamental architectural choice.