chore: update dependencies to latest within semver ranges

[guyathomas]

Summary

• Ran bun update across the root workspace and each package (packages/blog, packages/resume) to bump every dependency to the latest version satisfying its existing package.json semver range.
• Updated: turbo, react, react-dom, react-router, @testing-library/jest-dom, @testing-library/react, @types/react, @types/react-dom, vite, vitest, astro, js-yaml.
• Left out majors that fall outside current ranges (e.g. react-router 8, typescript 7, tailwindcss 4, vite 8, astro 7, vitest 4, jsdom 30) since those require dedicated upgrade work and weren't part of this pass.
• Toolchain change: also bumped packageManager from [email protected] → [email protected]. The regenerated bun.lock picked up a configVersion field that the older pin predates; this bump aligns the pin with the Bun version that actually produced the committed lockfile (flagged and confirmed via review — see PR discussion). This is a different risk category than the app-dependency bumps above, since it affects the install toolchain itself (CI/Vercel pick it up automatically via the packageManager field).

Test plan

• bun run build (turbo build) — both packages build successfully
• bun run test (turbo test) — blog test suite passes (3/3)
• Manual smoke test: served both packages/resume (astro preview) and packages/blog (vite preview) locally and screenshotted with Playwright — both render correctly; clicked the Blog nav link to confirm react-router (7.5→7.18) client-side routing still works
• Vercel deployment check is failing on this PR, but it's pre-existing and unrelated — confirmed by PR feat(resume): add profile photo to resume header #96 (unrelated, months-old, same base commit) showing the identical failure. See PR comments for details.

🤖 Generated with Claude Code

https://claude.ai/code/session_01MdKQDLUymgk4ibcbsvnGKw

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
resume	Error		Sep 3, 2026 8:26am UTC

[guyathomas]

The Vercel check is failing on this PR, but it's not caused by this change: PR #96 (unrelated, from months ago, "add profile photo to resume header"), based on the same main commit (2bf96dd), has the identical failure — same project (resume), same "Deployment has failed" status. That predates this PR entirely, so this looks like a pre-existing Vercel project configuration issue from the bun/turborepo monorepo conversion (root directory / build settings not yet updated on the Vercel dashboard side), not something in this PR's diff.

I don't have Vercel CLI/API access from this session to pull the deployment logs (vercel inspect dpl_9bMZZUTh9UtcX6oR5cUgsFDMX7YV --logs) to confirm the exact cause, and there's no existing fix to port. Locally, bun install + bunx turbo build --filter=@guythomas/resume (matching packages/resume/vercel.json) builds cleanly from a clean install, so the app itself builds fine — the failure appears to be Vercel-side config, not app code.

---

Generated by Claude Code

[claude]

Review

This is a scoped, low-risk dependency bump (bun.lock, root package.json, and the two workspace package.json files) — no application code changed, majors were deliberately excluded, and the PR description confirms build/test were run. A couple of things worth a look before merging:

1. bun.lock gained a configVersion field, but packageManager is still pinned to [email protected]

The regenerated lockfile adds a top-level "configVersion": 0 field and switches some optionalDependencies os entries to array form (e.g. "os": [ "linux", "android" ] for @turbo/linux-64) — neither of which appears in the lockfile on main. That implies the lockfile was generated with a newer local bun than the packageManager: "[email protected]" pin in package.json.

Both packages/blog/vercel.json and packages/resume/vercel.json run bun install as their Vercel installCommand. If Vercel/CI respects the packageManager field and installs [email protected] specifically, and that version predates the configVersion schema, install could fail or silently rewrite the lockfile at deploy time instead of using the one committed here. Worth either bumping packageManager to match the bun version actually used to generate the lock, or confirming a clean [email protected] install against this lockfile succeeds.

2. Minor: vite is no longer deduped to a single resolved version

Before this PR, bun.lock had one shared vite entry. After bumping the blog's vite devDependency to ^6.4.3, the lockfile now carries three separate resolutions — top-level [email protected], plus nested astro/[email protected] and vite-node/[email protected] — even though 6.4.3 satisfies astro's own "vite": "^6.4.1" peer range. Not a correctness issue, but it triples the installed vite payload and risks subtle dual-instance issues (e.g. plugin state) in tooling that inspects module identity across the two vite copies. Might be worth re-running bun install to see if a later bun resolver version collapses this, or just note it's expected given how bun resolves version bumps.

Other notes

• Range narrowing (e.g. turbo: ^2 → ^2.10.12, vite: ^6.3.0 → ^6.4.3) is expected bun update behavior (it pins ranges to the resolved version) rather than a mistake, just flagging since it does ratchet the minimum installable version up for anyone else installing fresh.
• No test coverage concerns — this is a dependency-only change and the existing suite already covers regressions; nothing new to add here.
• Security: nothing concerning in the version bumps themselves (no known-vulnerable versions being introduced that I could see); scope is appropriately limited to patch/minor updates.

Nice, tightly-scoped chore overall — just want the lockfile/packageManager mismatch double-checked before it hits deploy.

[guyathomas]

Thanks for the review — addressed both points:

1. packageManager mismatch: confirmed the pin ([email protected]) predates the configVersion field this lockfile now carries. I couldn't reach bun.sh from this session to install 1.2.0 and confirm the exact failure mode, so rather than leave it ambiguous I bumped the pin to [email protected] (the version that actually generated this lockfile) in 3b7462b. Re-verified bun install (no changes), bun run build, and bun run test all pass clean against it.
2. vite triple-resolution: this is expected bun resolver behavior given blog's vite bump to ^6.4.3 vs. astro's internal ^6.4.1 peer range — not a correctness issue, and not something worth forcing a dedupe for in a dependency-bump-only PR. Leaving as-is.

---

Generated by Claude Code

[claude]

Review

Straightforward, low-risk dependency bump — everything stayed within existing semver ranges and majors requiring dedicated upgrade work were correctly excluded (react-router 8, typescript 7, tailwindcss 4, vite 8, astro 7, vitest 4, jsdom 30).

Code quality / correctness

• Changes are mechanical (bun.lock, three package.json files) and internally consistent — no leftover version mismatches spotted.
• packageManager bump ([email protected] → 1.3.11) is a fairly large jump for a "routine dependency update" PR. It's not pinned anywhere else in .github/workflows/*.yml, so CI will pick it up automatically via the packageManager field — that's fine, just worth calling out explicitly in the PR description since it affects the toolchain itself, not just app dependencies, and is a different risk category than bumping react or astro.
• Minor pre-existing nit (not introduced here): typescript is declared as a devDependency in both the root package.json (^5.8) and packages/blog/package.json (now ^5.9.3 after this PR). The ranges still overlap so resolution is fine, but the root spec is looser than the workspace package's — could drift further apart over time. Not blocking, just something to tidy up eventually.

Bugs / behavior risk

• None spotted from the diff itself. The version bumps (react 19.1→19.2, react-router 7.5→7.18, vite 6.3→6.4, astro 5.16→5.18, tailwindcss 3.4.0→3.4.19) are all minor/patch within their major, so breaking changes are unlikely, but react-router jumping from .5 to .18 is a lot of minor releases at once — worth a quick manual smoke test of routing/navigation beyond the automated test suite, since routing libraries sometimes introduce subtle behavioral changes across minors.

Performance

• No concerns; this is a dependency-only change with no code paths affected.

Security

• Bumping dependencies forward is generally a security positive (picks up any patched CVEs in the interim). No new dependencies were added, and the diff is limited to lockfile/manifest — nothing to flag.

Test coverage

• The PR notes bun run build and bun run test both pass (blog suite 3/3). That's reasonable for a dependency bump, but the resume/astro package apparently has no test suite covering its build output beyond astro build succeeding — given astro moved 5.16→5.18 and tailwindcss patch-bumped, a quick visual check of the rendered resume site (or at least confirming the build output diff is unchanged) would add confidence beyond "it builds."

Overall: safe to merge as a routine dependency refresh. The one thing I'd want called out more explicitly is the packageManager (bun) version bump, since that's a toolchain change bundled into what's otherwise pure dependency housekeeping.

[guyathomas]

Addressed both points from the latest review:

• Updated the PR description to explicitly call out the packageManager bump as a toolchain change distinct from the app-dependency bumps.
• Did the suggested manual smoke test: served both packages/resume (astro preview) and packages/blog (vite preview) locally and screenshotted with Playwright. Both render correctly, and clicking through to /blog confirms react-router (7.5→7.18) client-side routing still works with no errors (aside from an unrelated missing-favicon 404).

---

Generated by Claude Code