Clear last 2 Dependabot alerts (sharp, @babel/core) via a Linux-generated lockfile

[schmug]

Task

Clear the last two open Dependabot alerts on this repo — sharp (high, patched in 0.35.0) and @babel/core (low, patched in 7.29.6) — by regenerating package-lock.json on Linux, not on macOS. Both are transitive and both are already permitted by their parents' declared ranges, so no package.json change is needed. The catch is that regenerating the lockfile on macOS silently drops platform metadata that Linux installs depend on, which is why this needs doing deliberately rather than with a local npm update.

Context

After merging 11 Dependabot PRs (postcss, vite, @astrojs/rss, svgo, fast-uri, brace-expansion, js-yaml, fast-xml-builder, fast-xml-parser, the actions group, and astro 6 → 7 in #176), open alerts went from 29 to 2. These are the remainder.

Neither is exploitable in this project as deployed — it is a static site with public/_routes.json excluding everything from the Functions runtime, so there is no server runtime and no attacker-controlled input reaches either package; both run at build time over owner-controlled content. This is alert hygiene, not an incident.

Nothing is version-pinning either package:

Package	Installed	Patched	Required by	Declared range
sharp	0.34.5	0.35.0	astro (optional)	^0.34.0 || ^0.35.0
@babel/core	7.29.0	7.29.6	@vitejs/plugin-react	^7.29.0
			eslint-plugin-react-hooks	^7.24.4

Why this needs a Linux lockfile

npm update sharp @babel/core --package-lock-only was run on macOS and produced correct versions (sharp 0.35.3, @babel/core 7.29.7) — but the resulting diff removed 22 "libc" entries and added none:

git diff package-lock.json | grep -cE '^\+.*"libc"'   # 0
git diff package-lock.json | grep -cE '^-.*"libc"'    # 22

Those fields are how npm selects the right @img/sharp-linux-* vs @img/sharp-linuxmusl-* binary for glibc vs musl. Dropping them degrades Linux installs — including Cloudflare Pages and GitHub Actions, both of which build on Linux. The change was reverted rather than committed. Dependabot itself generates lockfiles on Linux, so simply letting it open these PRs is a legitimate resolution.

Pointers

• package-lock.json — the only file expected to change.
• package.json — should not need editing. Specifically, do not npm install sharp@…; that adds sharp as a direct dependency (verified — it appends "sharp": "^0.35.0" to dependencies), changing the project's dependency surface for no reason. Use npm update, which respects existing ranges.
• .github/workflows/ci.yml — the suite that must stay green; it runs on ubuntu-latest, so it is a valid place to regenerate the lockfile if you go that route.
• Related, already-complete: #145 — the earlier four transitive alerts (devalue, fast-xml-builder, postcss, fast-xml-parser), all now fixed.

Suggested directions

• Preferred: let Dependabot do it. It builds on Linux and emits a correct lockfile. Confirm it opens PRs for these two; if it does not, find out why before hand-rolling.
• Regenerate inside a Linux container (node:22 image, npm update sharp @babel/core --package-lock-only) and commit that lockfile.
• Regenerate in a throwaway GitHub Actions run on ubuntu-latest and commit the artifact.

Constraints

• The committed package-lock.json must retain all "libc" entries. Check with the two grep -c commands above before committing — a diff that removes libc lines is wrong regardless of how correct the version numbers look.
• No package.json changes; no new direct dependencies.
• No npm audit fix --force — it downgrades @astrojs/check.
• Stay on Astro 7 / React 19 / Tailwind v4 — no framework upgrades smuggled in.

Acceptance criteria

• gh api repos/schmug/cortech.online/dependabot/alerts --jq '[.[]|select(.state=="open")]|length' returns 0.
• package-lock.json has sharp ≥ 0.35.0 and @babel/core ≥ 7.29.6.
• The diff removes zero "libc" lines.
• Diff is limited to package-lock.json.
• Full CI green on main — Verify (lint, typecheck, unit, build) and E2E (Playwright).

Out of scope

• The ESLint v10 ecosystem upgrade — tracked in #65.
• The yaml → @astrojs/check devDependency chain that only --force resolves.
• Adding lockfile-hygiene linting or CI enforcement of the libc invariant. Worth considering separately if this recurs.

Reasoning guidance

Prioritize responding quickly rather than thinking deeply — the version bump itself is mechanical. The only real judgment is where the lockfile gets generated; get that right and the rest follows.