Skip to content

chore(repo): pin lefthook in mise + make banned-strings bash-3.2 compatible#158

Merged
theagenticguy merged 1 commit into
mainfrom
fix/dev-tooling-bash32-lefthook-pin
May 29, 2026
Merged

chore(repo): pin lefthook in mise + make banned-strings bash-3.2 compatible#158
theagenticguy merged 1 commit into
mainfrom
fix/dev-tooling-bash32-lefthook-pin

Conversation

@theagenticguy
Copy link
Copy Markdown
Owner

Summary

Two dev-tooling gaps that silently broke git hooks on a stock macOS box (hit repeatedly while landing this session's PRs):

1. lefthook not pinned in misemise.toml [tools] didn't list lefthook, so a stale global mise lefthook@2.1.1 shadowed the 2.1.8 root devDep and failed lefthook.yml's min_version: 2.1.6. Every commit-msg/pre-push hook aborted with:

required lefthook version (2.1.6) is higher than current (2.1.1)

→ Pin lefthook = "2.1.8" in [tools] (matches the root devDep, satisfies the min_version floor). A stale global install can no longer shadow it.

2. banned-strings gate crashed on macOS bashscripts/check-banned-strings.sh used declare -A (bash 4+), but macOS ships bash 3.2, so the pre-commit gate died with declare: -A: invalid option instead of running:

scripts/check-banned-strings.sh: line 71: declare: -A: invalid option

The associative array (LITERAL_ALLOWLIST_REGEX) was an empty future-hook placeholder — no entries. → Replaced with a portable case function (literal_allowlist_regex) that returns the tolerated-substring regex per literal, preserving the exact extension point (LITERAL) printf '<regex>' ;;) without the bash-4 dependency.

Why it matters

These didn't fail CI (Linux runners have bash 5 + the right lefthook), so they were invisible there — but they block local commits/pushes for any macOS contributor, forcing --no-verify and skipping the very gates that exist to catch problems.

Verification

  • banned-strings under stock /bin/bash (3.2.57) → PASS (was: crash). Also passes via the hook's #!/usr/bin/env bash resolution.
  • mise install lefthook → resolves 2.1.8; mise which lefthook confirms.
  • This PR's own commit-msg (commitlint) + pre-push (test/typecheck/verdict) hooks ran natively and passed — end-to-end proof the lefthook pin works.
  • Banned-string detection logic unchanged (the case function returns empty for every literal, identical to the empty array).

Test plan

  • /bin/bash scripts/check-banned-strings.sh exits 0 on bash 3.2
  • mise resolves lefthook 2.1.8
  • commit-msg + pre-push hooks pass natively (no --no-verify)

…atible

Two dev-tooling gaps that broke git hooks on a stock macOS box:

- mise.toml [tools] didn't pin lefthook, so a stale global mise lefthook@2.1.1
  shadowed the 2.1.8 devDep and failed lefthook.yml's min_version: 2.1.6 — every
  commit-msg/pre-push hook aborted with 'required lefthook version (2.1.6) is
  higher than current (2.1.1)'. Pin lefthook=2.1.8 (matches root devDep).
- scripts/check-banned-strings.sh used 'declare -A' (bash 4+), but macOS ships
  bash 3.2, so the pre-commit banned-strings gate crashed with 'declare: -A:
  invalid option' instead of running. The associative array was an empty
  future-hook placeholder; replace with a portable 'case' function that keeps
  the same per-literal-allowlist extension point.

Validated: banned-strings now PASSes under /bin/bash 3.2; mise resolves
lefthook -> 2.1.8.
@theagenticguy theagenticguy merged commit 68b1f37 into main May 29, 2026
40 of 45 checks passed
@theagenticguy theagenticguy deleted the fix/dev-tooling-bash32-lefthook-pin branch May 29, 2026 11:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant