bump dependencies to resolve dependabot

[yangm2]

What type of PR is this? (check all applicable)

• Refactor
• Feature
• Bug Fix
• Optimization
• Documentation Update
• Infrastructure
• Maintenance

Description

bump dependencies to resolve dependabot

Related Tickets & Documents

• Related Issue

  • https://github.com/codeforpdx/tenantfirstaid/security/dependabot/188
  • https://github.com/codeforpdx/tenantfirstaid/security/dependabot/191
  • https://github.com/codeforpdx/tenantfirstaid/security/dependabot/198
  • https://github.com/codeforpdx/tenantfirstaid/security/dependabot/199
  • https://github.com/codeforpdx/tenantfirstaid/security/dependabot/200
  • https://github.com/codeforpdx/tenantfirstaid/security/dependabot/201

• Closes #

QA Instructions, Screenshots, Recordings

Please replace this line with instructions on how to test your changes, a note on the devices and browsers this has been tested on, as well as any relevant images for UI changes.

Added/updated tests?

• Yes
• No, and this is why: dependency bump
• I need help with writing tests

Documentation

• If this PR changes the system architecture, Architecture.md has been updated

[optional] Are there any post deployment tasks we need to perform?

[yangm2]

@claude code-review

[claude]

Claude finished @yangm2's task in 2m 35s —— View job

---

Code Review

• Gather context (PR diff, changed files)
• Review frontend/package.json changes
• Review frontend/package-lock.json consistency
• Verify install/build/test still work — ⚠️ blocked, see note
• Post review

---

Summary

The dependency bumps themselves look clean and low-risk: everything that moved is dev-tooling, the lockfile is internally consistent with package.json, and lockfileVersion: 3 is preserved. My one substantive concern is the new allowScripts field, which doesn't appear to be wired to anything.

🔴 allowScripts looks like a no-op

frontend/package.json:55-57

"allowScripts": {
  "esbuild@0.25.12": true
}

npm has no top-level allowScripts field in package.json — unknown top-level keys are silently ignored. The field name comes from other tooling:

• @lavamoat/allow-scripts reads it, but nested under lavamoat.allowScripts (not top-level), and requires the package to be installed plus allow-scripts wired into a lifecycle script. grep -c lavamoat frontend/package-lock.json returns 0.
• pnpm's equivalent is pnpm.onlyBuiltDependencies; Yarn Berry's is dependenciesMeta.<pkg>.built.

This repo installs with plain npm ci in every lane (.github/workflows/pr-check.yml:150, deploy.staging.yml:47, deploy.production.yml:49, frontend/Dockerfile:18) and there's no .npmrc or --ignore-scripts in any of them, so install scripts already run unrestricted and nothing consumes this key. A corroborating signal: npm did not mirror the field into the lockfile's root packages[""] entry (frontend/package-lock.json:7-42), because it doesn't recognize it.

If the intent was to restrict install scripts to an allowlist, that needs --ignore-scripts/.npmrc plus a real allowlist tool, and it would be a meaningful infra change worth its own PR. If it was exploratory, I'd drop it — dead config in package.json is easy to mistake for an active security control later. Fix this →

🟡 If the field stays, the exact version pin will go stale

esbuild@0.25.12 matches the current lockfile (frontend/package-lock.json:3093-3094), but esbuild is transitive via vite, so the very next vite bump silently invalidates the entry with no error to tell you. Any allowlist keyed on exact versions needs a check that fails when it drifts, otherwise it's worse than not having one. Fix this →

🟡 Alert coverage is worth double-checking

The PR links 6 Dependabot alerts, but nothing under dependencies changed — the entire diff is dev-tree:

Package	Change
vitest, @vitest/{coverage-v8,expect,mocker,pretty-format,runner,snapshot,spy,utils}	4.1.8 → 4.1.11
@humanfs/core / node	0.19.1 → 0.19.2 / 0.16.7 → 0.16.8 (+ new @humanfs/types 0.15.0)
browserslist chain (baseline-browser-mapping, caniuse-lite, electron-to-chromium, node-releases, update-browserslist-db)	routine data refresh
es-module-lexer, expect-type, js-yaml, nanoid, obug, std-env, tinyexec, tinyrainbow	patch/minor

That's plausible for alerts on the test/build toolchain, but 6 alerts closing off a dev-only bump is worth confirming. Could you note in the PR description which alert each bump closes, and whether any remain open after this? (nanoid 3.3.17 → 3.3.19 in particular is past the version that fixed its known advisory, so it reads as incidental rather than targeted.)

✅ What looks right

• vitest and @vitest/coverage-v8 are bumped in lockstep to ^4.1.11. That matters — @vitest/coverage-v8 declares an exact-version peer on vitest, so bumping one alone breaks installs. Good catch keeping them together.
• package.json ranges and the lockfile agree (package-lock.json:41,53 vs package.json:41,53), so npm ci won't fail the sync check.
• The vitest range on main was ^4.0.1 while the lockfile already had 4.1.8; tightening to ^4.1.11 makes the declared floor honest.
• Dev-only blast radius — the production image copies only dist/ (frontend/Dockerfile:66), so none of this ships to users.
• No package.json → Architecture.md implications; skipping tests is the right call here.

Notes on verification

I could not run npm ci, npm audit, or the test suite in this sandbox (network/command approval restrictions), and I couldn't query the Dependabot alerts API to confirm which advisories these bumps close. So my read of the lockfile is static-analysis only — CI on this PR is the real gate for the build/test side. If you want me to actually run the install and suite, the job needs npm and gh api in --allowedTools.

The PR description still has the placeholder QA line (_Please replace this line..._) — probably fine to leave for a dependency bump, but worth a one-liner like "CI green" for the record.
· bump-npm-deps