chore(deps): bump @tschk/moonshine packages to 0.4.0

[undivisible]

moonshine 0.4.0 release — perf (route-discovery caching, bounded Vercel adapter worker pool), tests, type-safety cleanups.

---

Note

Medium Risk
Moonshine is the app’s core build and server runtime; a minor framework bump can affect compile output, routing, or deploy behavior until CI and smoke tests pass.

Overview
Updates all @tschk/moonshine dependencies in web/app/package.json from ^0.3.7 to ^0.4.0, including runtime packages (moonshine, compiler, framework, react, next, server, deploy-bun) and @tschk/moonshine-cli in devDependencies. There are no application source changes—only this version bump for the Moonshine build/dev/serve stack.

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

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: Lockfile not updated for bump
  • Regenerated web/app/bun.lock so bun install --frozen-lockfile resolves @tschk/moonshine* to 0.4.0 and matches package.json.

_{You can send follow-ups to the cloud agent here.}

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

[cursor]

Lockfile not updated for bump

High Severity

Moonshine packages were bumped to ^0.4.0 in package.json, but bun.lock still pins ^0.3.7 and resolves 0.3.7. Dockerfile and test.sh run bun install --frozen-lockfile, so image builds and CI fail instead of installing 0.4.0.

Additional Locations (1)

• web/app/package.json#L65-L66

 

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

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: bfec26e4aa

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Regenerate bun.lock alongside the version bump

In every clean web-app CI or Docker build, these new ^0.4.0 requirements conflict with the unchanged bun.lock, whose root entries and resolved Moonshine packages remain at 0.3.7. Both .github/workflows/web-checks.yml and web/app/Dockerfile install with bun install --frozen-lockfile; bun install --help defines that flag as “Disallow changes to lockfile,” so the install cannot reconcile this mismatch and the build/deployment stops before compilation. Regenerate and commit web/app/bun.lock with these manifest changes.

AGENTS.md reference: web/app/AGENTS.md:L9-L16

Useful? React with 👍 / 👎.

[Git-on-my-level]

Thanks for tracking the 0.4.0 release so quickly — the perf goals (route-discovery caching, bounded Vercel adapter worker pool) look worthwhile, and keeping the whole @tschk/moonshine* set moving in lockstep is the right instinct. Unfortunately the branch can't build or typecheck with 0.4.0 as published, so I'm requesting changes until the dependency resolution is fixed.

What I checked:

• web/app/package.json — clean and purely mechanical: 8 bumps ^0.3.7 → ^0.4.0 (7 runtime deps + @tschk/moonshine-cli devDep), no other edits. Right shape for this PR.
• web/app/bun.lock — regenerated resolutions. Top-level entries move to 0.4.0 with new integrity hashes; because every 0.4.0 package still declares its sibling deps as ^0.3.6, the regen adds nested 0.3.7 duplicates (e.g. "@tschk/moonshine/@tschk/moonshine-router", "@tschk/moonshine-cli/@tschk/moonshine-next" pinned at 0.3.7). The prettier / prettier-plugin-tailwindcss entries appearing here are just the lockfile catching up with devDeps already on main — not a new addition in spirit.

Both red checks come from that mixed-version tree:

• Build: moonshine build fails with error: No matching export in "node_modules/@tschk/moonshine-next/node_modules/@tschk/moonshine/src/router.ts" for import "isExternal" (raised from @tschk/moonshine-next/src/link.ts:20).
• Hygiene: bunx tsc --noEmit fails with TS2305: Module '"@tschk/moonshine/router"' has no exported member 'isExternal' at moonshine-next/src/link.ts(20,10) and moonshine/src/router.ts(14,3).

Root cause (verified against the published tarballs, not just the logs): @tschk/moonshine@0.4.0 and @tschk/moonshine-next@0.4.0 now import isExternal from @tschk/moonshine-router, and that export only exists in @tschk/moonshine-router@0.4.0 (src/navigation.ts). But all 0.4.0 packages still declare ^0.3.6 sibling ranges, which resolve to nested 0.3.7 copies that don't have it — so any fresh install of 0.4.0 hits this, not just our lockfile. (In 0.3.7, moonshine-next/src/link.ts defined its own local isExternal, so main is unaffected.) Side note while you're in there: @tschk/moonshine-deploy-bun@0.4.0 dropped its @tschk/moonshine-adapter-conformance dependency — looks intentional, just flagging it.

Two ways forward, either works:

1. Publish 0.4.1 upstream with sibling ranges bumped to ^0.4.0, then re-run the bump here, or
2. Add a root override (bun overrides/resolutions) pinning the @tschk/moonshine* siblings to 0.4.0 so the nested 0.3.7 copies disappear, and regenerate the lockfile.

Once Build/Hygiene are green, this core build/runtime bump should still get a maintainer sign-off before merge since it's the app's framework stack.

---

by AI on behalf of David — if you need David’s attention urgently, please @Git-on-my-level and escalate with need human response.

[Git-on-my-level]

Thanks for the quick regeneration — this resolves my earlier change request. Verified on c7455b7:

• web/app/package.json — unchanged from my last pass: 8 mechanical bumps ^0.3.7 → ^0.4.0 (7 runtime packages + @tschk/moonshine-cli devDep), nothing else touched.
• web/app/bun.lock — the tree is now uniform: every @tschk/moonshine* entry resolves to a single 0.4.1 version (the caret ranges pick up the 0.4.1 patch published after 0.4.0), the nested 0.3.7 duplicates that caused the earlier isExternal export mismatch are gone, and no 0.3.7 reference or nested @tschk duplicate remains. Build and Hygiene are green on this exact head, so that blocker is closed.
• The bulk deletions in bun.lock (mermaid, the d3 suite, cytoscape, katex, dayjs, dompurify, ~140 entries) are stale orphan resolutions — none of them are declared in web/app/package.json on main, so this is long-overdue lockfile hygiene rather than dropped functionality. The small additions (@js-sdsl/ordered-map, a nested @grpc/proto-loader) are transitives of the existing @grpc/grpc-js@1.14.4, and @tschk/crepus-moonshine / @tschk/crepuscularity-wasm were already on main and simply move in lockstep with the rest of the @tschk set.

Two non-blocking notes: the title says 0.4.0 while the lock resolves 0.4.1 — expected with caret ranges, just worth knowing when reading the lock later; and if 0.4.2 lands soon a re-run of bun install will pick it up automatically.

Keeping dependency-review for a maintainer pass over the 0.3.x → 0.4.x minor bump of the app's build/server runtime — that's a human sign-off on the framework upgrade itself, not a defect flag. My earlier changes-requested review is dismissed as resolved.

---

by AI on behalf of David — if you need David’s attention urgently, please @Git-on-my-level and escalate with need human response.

Resolved in c7455b7: bun.lock now resolves all @tschk/moonshine* packages to a single 0.4.1 version with no nested 0.3.7 duplicates; Build and Hygiene are green on this head.