The apps/web/**/*.{ts,tsx} rule's bash -c wrapper did not forward "$@",
so lint-staged's file arguments were dropped and eslint fell back to its
default target (the entire workspace). Combined with --max-warnings=0,
that meant any commit touching a single TS file failed on the ~1 170
pre-existing warnings in files unrelated to the change. This is the root
cause of the --no-verify workarounds in commits 0e7097ed1 (J1) and
0589ec9fc (J5).
Change: add "$@" forwarding and the -- sentinel, matching the pattern
already used by the veza-backend-api Go rule a few lines below:
"bash -c 'cd veza-backend-api && gofmt -l -w \"$@\"' --"
Now eslint receives the absolute paths lint-staged passes (lint-staged
15 defaults to absolute paths — see --relative, default false), and
only the staged TS files are checked.
Verification: ran the exact wrapper manually with the two paths staged
in J5 (domain.ts + index.ts) — exit 0, 0 warnings, whereas the unfixed
wrapper reported 1 170 warnings on the same invocation.
Not fixed here:
- The apps/web tsc command still runs project-wide (which is the
intended behavior for --noEmit typecheck — it ignores file args
anyway because of -p tsconfig.json)
- The underlying 1 170-warning ESLint backlog; that backlog is
legitimate tech debt to pay down separately, not something the
pre-commit hook should force on each touching commit
