chore(repo): pin lefthook in mise + make banned-strings bash-3.2 compatible#158
Merged
Merged
Conversation
…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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 mise —
mise.toml [tools]didn't list lefthook, so a stale globalmise lefthook@2.1.1shadowed the2.1.8root devDep and failedlefthook.yml'smin_version: 2.1.6. Every commit-msg/pre-push hook aborted with:→ 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 bash —
scripts/check-banned-strings.shuseddeclare -A(bash 4+), but macOS ships bash 3.2, so the pre-commit gate died withdeclare: -A: invalid optioninstead of running:The associative array (
LITERAL_ALLOWLIST_REGEX) was an empty future-hook placeholder — no entries. → Replaced with a portablecasefunction (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-verifyand skipping the very gates that exist to catch problems.Verification
banned-stringsunder stock/bin/bash(3.2.57) → PASS (was: crash). Also passes via the hook's#!/usr/bin/env bashresolution.mise install lefthook→ resolves 2.1.8;mise which lefthookconfirms.casefunction returns empty for every literal, identical to the empty array).Test plan
/bin/bash scripts/check-banned-strings.shexits 0 on bash 3.2