chore: pin esbuild past the GHSA-g7r4-m6w7-qqqr range in web/cli/tui

`npm audit` (dev included) reported a low-severity advisory against
`esbuild` in three of the four client installs. It is not in the
production tree — `npm audit --omit=dev` has been clean everywhere since
2058 — but a permanently non-clean audit trains people to skim the
channel, which is the same argument 2058 made.

`tsup@8.5.1` declares `esbuild: ^0.27.0`, and the advisory covers
0.27.3 - 0.28.0 with 0.27.7 the last 0.27.x, so there is no upward
escape inside tsup's declared range. `npm audit fix` "resolves" it by
silently downgrading to 0.27.2 across three installs — the trap hit and
reverted during 2058. An `overrides` entry forces the copy above the
range instead.

- Add `"overrides": { "esbuild": "^0.28.2" }` to clients/{web,cli,tui}.
  That also covers the tui's `tsx` copy (0.28.0), so no separate update
  is needed.
- Re-resolve each lockfile. Every changed entry is an esbuild one: the
  nested `tsup/node_modules/esbuild` and `tsx/node_modules/esbuild`
  copies collapse into the single deduped 0.28.2, and no other package
  moves.
- Document the pin in AGENTS.md, including when to drop it.

The real gate here is the build, not the audit: this puts tsup on an
esbuild major it does not declare. `npm run build` succeeds for all
three clients, and `npm run ci` passes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0177mPHAdECD18nLLCTwR5rh
Signed-off-by: cliffhall <cliff@futurescale.com>
This commit is contained in:
cliffhall 2026-08-24 20:23:24 -04:00
commit 3be4230391

View file

@ -294,6 +294,8 @@ The same **placement** rule covers anything reached only through **root-owned co
**`ink` is the single exemption, and it is justified by cost, not by safety.** Bundling it works but adds ~1.4MB (`react-reconciler` + `yoga-layout`, plus a `createRequire` banner, since inlined CJS calls `require` at runtime and esbuild's ESM interop rejects that without a real `require` in scope). **Never justify an exemption by a peer range** — `ink` briefly carried "its `">=19"` peer keeps npm honest", which is false: a consumer pinning React 19.0 satisfies `">=19"` while a narrower range of ours nests underneath. What actually makes the exemption safe is a *different* lever: the **root `react` range stays open to the whole major (`^19.0.0`)**, so npm can dedupe our React with whatever React 19 a consumer pins and an external `ink` lands on the same copy the bundle uses. Narrowing it (e.g. back to `^19.2.4`) silently reopens the crash for the renderer itself, which breaks TUI *startup*, not just its forms. `clients/tui/__tests__/tsupConfig.test.ts` enforces all of it: React-rendering deps inlined, each exempt package both external and root-declared, and the root range pinned to `ink`'s peer floor.
**An `overrides` entry is how a transitive dependency gets pinned past its parent's declared range — reach for it before `npm audit fix`.** `clients/{web,cli,tui}/package.json` each override `esbuild` to `^0.28.2` (#2062). `tsup@8.5.1` declares `esbuild: ^0.27.0`, and GHSA-g7r4-m6w7-qqqr covers `0.27.3 - 0.28.0` with `0.27.7` the last 0.27.x — so there is no *upward* escape inside `tsup`'s range, and `npm audit fix` "resolves" it by silently **downgrading** to `0.27.2` across three installs (~700 lines of lockfile churn for a low-severity dev-only advisory; tried and reverted in #2058). The override forces the single deduped copy above the range instead, which also collapses the nested `tsup/node_modules/esbuild` and `tsx/node_modules/esbuild` copies into it. Two things this costs: it puts `tsup` on an esbuild **major it does not declare**, so `npm run build` for web/cli/tui — not `npm audit` — is the real gate on such a pin; and it is invisible to the audit once clean, so **when `tsup` widens its range to `^0.28`, drop the override rather than carrying it forever**. The same file's `ink-select-input` entry is a different case entirely (it pins a bundled dep's transitive resolution, which npm ignores for a consumer install — see above), so don't read one as precedent for the other.
The v1 SDK (`@modelcontextprotocol/sdk`) is **not** a dependency of this repo and must not become one — v2 uses the packages above. It appears in the lock files only as a `"peer": true` entry pulled in by `ext-apps`.
## Contributing