fix(deps): bump hono, fast-uri and body-parser to clear 10 dependabot alerts

[yakimoto]

Clears 10 of the 15 open Dependabot alerts on this repo, including 3 of the 4 highs. Lockfile only — sdk-typescript/pnpm-lock.yaml is the single file changed.

package	from → to	alerts cleared	patched floor
hono	4.12.23 → 4.12.32	7 (1 high, 6 medium)	4.12.27
fast-uri	3.1.2 → 3.1.4	2 (both high)	3.1.4
body-parser	2.2.2 → 2.3.0	1 (low)	2.3.0

All three are transitive — no package.json in the workspace declares any of them — so no declared range needed to move.

Why the lockfile is still trustworthy

A dependency change that looks applied but isn't is the expensive failure mode here, so this is stated as a receipt rather than an assurance:

$ git diff -U0 -- sdk-typescript/pnpm-lock.yaml | grep -c "specifier:"
0

$ pnpm install --frozen-lockfile
Lockfile is up to date, resolution step is skipped

Zero specifier: lines means no declared range shifted; --frozen-lockfile succeeding means the lockfile is genuinely consistent with the untouched manifests rather than merely looking plausible. And the bump is on disk, not just in YAML:

$ node -e "console.log(require('./node_modules/.pnpm/hono@4.12.32/node_modules/hono/package.json').version)"
4.12.32

Verification — local, because CI cannot run

Actions are refusing every job org-wide on an account-level billing lock (plan=free, locked=yes as of 2026-07-28T01:25:58Z). There will be no check on this PR, and an absent check is not a passing one. So the suite was run against the exact committed bytes:

pnpm -r build       clean across all 49 packages
pnpm -r test        exit 0 — 143 tests / 52 files / 48 packages green, zero failures
pnpm -r type-check  zero `error TS`

(pnpm -r test fails on a clean tree until pnpm -r build runs — @wave-av/core has no dist/ to resolve. That ordering is pre-existing and unrelated to this change.)

The 5 alerts left open, on purpose

vite (2 alerts, one HIGH) and esbuild (1, low) — dev tooling, not shipped. They enter solely through vitest ^4.1.4, a devDependency of every package. They are never present in a published tarball. Dependabot reports them as scope: runtime, which is a pnpm-lockfile scope misattribution — worth knowing before anyone reads "1 high, runtime" and escalates.

Moving them requires either a pnpm.overrides pin — a permanent manifest pin, for dev-only tooling — or a vitest bump, which Renovate #24 already proposes independently. Letting #24 do it is the cleaner path. If you'd rather treat build tooling as in-scope because it runs inside the provenance-signed release pipeline, say so and I'll add the override — that's a defensible call and I'd rather you make it than inherit my default.

@hono/node-server (1, medium) needs 1.19.14 → 2.0.5 — a major jump on a transitive dep. That does not belong in a patch-level security change; it needs its own PR with its own verification.

Incidental churn, disclosed

Re-resolution inside already-declared ranges, all from the tsup build-tool subtree: lightningcss 1.32.0→1.33.0, postcss 8.5.15→8.5.23, nanoid 3.3.12→3.3.16, @napi-rs/wasm-runtime 1.1.4→1.1.6, @tybys/wasm-util 0.10.2→0.10.3, plus new tinyglobby/fdir/picomatch entries. Unavoidable when a lockfile is refreshed; called out so it isn't mistaken for scope creep.

One thing that was reverted rather than shipped: the first attempt ran pnpm update --recursive including vitest, which silently rewrote all 48 package.json files — collapsing single-line JSON objects across every manifest and unescaping — into a literal em-dash inside published description fields. 928 insertions of pure formatting noise riding inside a security fix. Fully reverted before the real change was made; --lockfile-only does not protect manifests from --recursive.

Relationship to the other open PRs

Independent of #45 and #47 (both touch .github/workflows/publish-npm.yml; this touches only the lockfile), so it can land in any order. Based directly on main @ 9eb128a.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

---

Note

Low Risk
Runtime risk is low because published SDK code paths are unchanged and only transitive lockfile versions move; residual risk is limited to dev/build tooling behavior from the incidental tsup/vite subtree bumps.

Overview
Lockfile-only update to sdk-typescript/pnpm-lock.yaml—no package.json specifier changes. It bumps transitive packages (mainly via @modelcontextprotocol/sdk and the tsup/vitest dev toolchain) to address Dependabot alerts:

• hono 4.12.23 → 4.12.32
• fast-uri 3.1.2 → 3.1.4
• body-parser 2.2.2 → 2.3.0 (including content-type behavior in that subtree)

Re-resolution also refreshes related build-tool entries already within declared ranges (postcss, lightningcss, nanoid, wasm helpers, tinyglobby/fdir/picomatch), so every tsup devDependency line now pins to postcss@8.5.23 instead of 8.5.15.

^{Reviewed by Cursor Bugbot for commit 8aee779. Configure here.}

---

Summary by cubic

Lockfile-only security bumps to clear 10 of 15 Dependabot alerts, including 3 highs, by upgrading transitive hono, fast-uri, and body-parser. No code or manifest changes.

• Dependencies
  • Upgrades: hono 4.12.23 → 4.12.32 (clears 7 alerts), fast-uri 3.1.2 → 3.1.4 (clears 2 highs), body-parser 2.2.2 → 2.3.0 (clears 1 low).
  • Scope: sdk-typescript/pnpm-lock.yaml only; all are transitive; pnpm install --frozen-lockfile is clean. Incidental re-resolves in the tsup toolchain (e.g., postcss, lightningcss) stay within declared ranges.
  • Remaining alerts (left as-is): vite/esbuild via vitest (dev-only) and @hono/node-server (requires a major bump).

^{Written for commit 8aee779. Summary will update on new commits.}

[changeset-bot]

⚠️ No Changeset found

Latest commit: 8aee779

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_abfb352f-4bcc-44d3-992a-ebfc9659c6df)

[coderabbitai]

Important

Review skipped

Review was skipped due to path filters

⛔ Files ignored due to path filters (1)

• sdk-typescript/pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including **/dist/** will override the default block on the dist directory, by removing the pattern from both the lists.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: e737caa8-70d8-4dc0-b4cc-8d92b9adb401

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/security-dep-bumps

✨ Simplify code

• Create PR with simplified code
• Commit simplified code in branch fix/security-dep-bumps

---

_{Comment @coderabbitai help to get the list of available commands.}