chore: Pre-commit hooks

[gcgoncalves]

Add prettier, eslint and unit tests to the pre-commit hook.

[marekdano]

Suggestions (non-blocking)

• The hook is heavy for a pre-commit: format:check + lint (whole
  src+e2e) + full build + full vitest run. That's likely tens of seconds
  to minutes on every commit, which tends to push people toward
  git commit --no-verify. Common pattern: run lint-staged (prettier/eslint on
  staged files only) at pre-commit, and move build + the full test suite to a
  pre-push hook or rely on CI. That keeps commits fast while still gating
  pushes.
• Stale comment in eslint.config.js: it warns about "a
  second, differently-configured prettier.config.js one directory up (repo
  root)." That referred to the old monorepo layout; there's no such file in this
  standalone repo. Now that .prettierrc is added, that comment is misleading
  and could be trimmed. Pre-existing, so optional.

[gcgoncalves]

Great point, @marekdano! I'll update accordingly.

[marekdano]

Verified on 984705d: npm run build ✅ (outputs to dist/), vitest run ✅ 148 files / 2687 passed / 1 skipped, eslint src e2e ✅ clean, prettier --check ✅ clean.

Nice iteration on the last round — lint-staged at pre-commit with the heavy work moved to pre-push is exactly the shape that keeps commits fast, and the stale eslint comment is gone. Two valuable side fixes rode along: .prettierrc un-breaks npm run lint (eslint.config.js readFileSyncs that file, which didn't exist on main, so lint crashed on a fresh clone), and outDir: "dist" now matches what the README already documents.

Blocking

.husky/post-checkout, .husky/post-commit, and .husky/post-merge recurse into husky's own dispatcher. Each file's entire content is a single line pointing back at the internal hook:

.husky/_/post-commit

Husky sets core.hooksPath=.husky/_, and .husky/_/h ends with sh -e "$s" where $s resolves to .husky/<hook-name>. So git runs _/post-commit → which runs .husky/post-commit → whose body re-invokes _/post-commit, and around again.

Reproduced with husky 9.1.7 and these exact file bytes: a real git commit produced 72 nested dispatches in 4 seconds, stopping only because I capped the process budget. Uncapped it climbs until the per-user process limit is hit (~2400 levels, on the order of minutes), during which nothing on the machine can fork. Since git ignores post-* exit codes the commit itself still lands — the cost is the stall, not a failed operation. post-checkout and post-merge are byte-identical in pattern and go through the same dispatcher.

Simplest fix: delete all three. Husky's dispatcher already exit 0s when no matching .husky/<name> exists, so nothing is lost. If they were meant to carry a real command (an npm install after a branch switch, say), that command should replace the self-reference.

Functionally impacting

"prepare": "husky" breaks production installs. Confirmed: npm ci --omit=dev exits 127 with sh: husky: command not found, since husky is a devDependency but prepare still runs. Any Docker or prod install path hits this. Husky's docs suggest "prepare": "husky || true" for exactly this case.

"export-schema": "cd .. && make export-schema" re-introduces a monorepo assumption in the same PR that removes the others (../mcpgateway/static/app, the vite outDir). In a standalone clone the parent directory is arbitrary — in the sibling-repo layout it lands somewhere with no Makefile. It's also unreachable today: pregenerate guards on test -f openapi.json, and openapi.json is committed at repo root (README pins it to API v1.0.7). Probably cleanest to drop both scripts; if they're groundwork for a future workflow, they'd need a real path.

Suggestions

• lint-staged globs skip root-level files. {src,e2e}/**/*.{ts,tsx,css,json} misses vite.config.ts, eslint.config.js, the other *.config.ts files, index.html, and *.md — meaning the files this PR itself edits wouldn't be checked by its own hook. One option: "*.{ts,tsx,js,mjs,json,css,md}": "prettier --write --ignore-unknown" with .prettierignore doing the excluding, keeping eslint --fix scoped to {src,e2e}/**/*.{ts,tsx}.
• Nothing gates formatting or lint on push, and there's no CI in the repo (no .github/ at all). Anything committed with --no-verify sails straight through, since pre-push only runs build + test. eslint src e2e finishes in seconds, so adding it to pre-push is cheap insurance. A CI workflow is the real backstop, but that's its own PR.
• "lint-staged": "lint-staged" is redundant — the hook calls npx lint-staged directly. Worth noting husky already puts node_modules/.bin on PATH, so a bare lint-staged in the hook works and skips npx's resolution step.

Minor

• vite.bff.config.ts's comment still describes mcpgateway/static/app and client/server/… — same monorepo cleanup as the vite.config.ts change.
• The description is now out of date: it says tests run in pre-commit, but they moved to pre-push, and it doesn't mention the outDir fix, .prettierrc, or the AuthContext.test.tsx change. That test fix is correct and matches the {authenticated, user, csrfToken} shape the rest of the file uses — just worth calling out, since it's unrelated to hooks.

[gcgoncalves]

@marekdano addressed! :D

[marekdano]

The looks good!

I left a comment below

[marekdano]

lint-staged@17.3.0 declares node: ">=22.22.1". The repo does not advertise a matching Node floor (.nvmrc is absent and package.json has no engines), while the existing toolchain was previously compatible with older Node 22 / Node 20 setups. As written, npm install and therefore the new Husky flow can fail outright for contributors on a still-common Node version. This needs either a compatible lint-staged version or an explicit repo-wide Node version bump documented and enforced.

[marekdano]

The changes looks good now!

LGTM 🚀

[vishu-bh]

LGTM once conflicts are addressed