fix(rivetkit-core): ship inspector UI bundle inside the published crate

[abcxff]

No description provided.

[abcxff]

Stack for rivet-dev/actors

• #5683 fix(rivetkit-core): tolerate workflow not_configured in insp …
• #5684 feat(rivetkit-rust): select serverless vs envoy runner mode …
• #5682 fix(rivetkit-core): scope actor stops to their generation
• #5680 fix(rivetkit-core): ship inspector UI bundle inside the publ … 👈
• #5681 fix(rivetkit): wire abort signal through client get/getOrCre …
• main

Get stack: forklift get 5680
Push local edits: forklift submit
Merge when ready: forklift merge 5680

_{change svspuzzm}

[claude]

Review: ship inspector UI bundle inside the published crate

Overall this is a solid, well-tested fix for a real gap (published rivetkit-core crate silently serving ui_asset_not_found because frontend/dist never made it into the .crate archive). The two-layer verification (cargo package --list for archive inclusion + a gated integration test for runtime serving) is a good design that catches the actual root cause instead of just asserting the fallback doesn't trigger.

A couple of things worth addressing before merge:

1. Generated inspector-dist/{inspector-ui,inspector-tab}/ isn't gitignored

rivetkit-rust/packages/rivetkit-core/inspector-dist/README.md states the generated bundle contents are "intentionally not committed," and scripts/stage-inspector-bundle.mjs is documented for local use (its header comment tells a developer to run it directly). But there's no .gitignore entry anywhere (root .gitignore only ignores frontend/dist/, not inspector-dist/inspector-ui or inspector-dist/inspector-tab) to actually enforce that.

This repo uses jj on top of git, where the working copy auto-snapshots every file that isn't gitignored. A contributor who runs the staging script locally (exactly as instructed in its header comment) will have the generated JS/CSS bundle silently swept into their next jj new/jj describe revision unless they remember to manually exclude it. Worth adding a .gitignore under inspector-dist/ for the two generated subdirectories.

2. Staged in-crate bundle silently shadows fresher frontend builds

build.rs::stage_bundle (around lines 48-54) now prefers inspector-dist/<name>/ over ../../../frontend/dist/<name>/ whenever the in-crate marker file exists:

let source = if in_crate.join(marker).is_file() {
    Some(in_crate)
} else if monorepo.join(marker).is_file() {
    Some(monorepo)
} else {
    None
};

Nothing cleans up inspector-dist/inspector-ui / inspector-tab after staging (no rm step in the workflow, no gitignore-driven ephemerality). So once a developer runs stage-inspector-bundle.mjs locally once, e.g. to test the publish verification as the script's own docstring suggests, every subsequent cargo build/cargo test -p rivetkit-core keeps embedding that stale staged snapshot instead of picking up new frontend/dist output, with no warning that this is happening. This is a non-obvious footgun that could cause confusing "I rebuilt the frontend but the UI didn't change" debugging later. Consider either preferring the freshest source (compare mtimes) or making it obvious/loud when the in-crate copy is shadowing a newer monorepo build.

Minor / non-blocking

• The "Build Inspector UI bundle" / "Stage" / "Verify" steps in publish.yaml aren't gated on contains(needs.context.outputs.targets, 'rivetkit'), so they run even for previews that don't touch rivetkit-core (e.g. engine-only or container-runner-only previews). This matches the existing (also ungated) "Dry-run Rust crate publish" / "Publish Rust crates" steps, so it's consistent with current behavior rather than a regression, but every preview build now also pays for a full frontend build. Worth confirming that's intentional.
• stage-inspector-bundle.mjs's failure message suggests pnpm turbo build:inspector-ui ... while the workflow actually runs npx turbo build:inspector-ui .... Cosmetic only.

Nice to have

• tests/inspector_bundle.rs correctly stays a no-op without RIVETKIT_ASSERT_INSPECTOR_BUNDLE, so it won't break normal cargo test for contributors without a built frontend.
• Using cargo package --list instead of a full package/publish avoids touching crates.io for not-yet-published sibling crates during the ordered publish sequence, exactly the right way to test this without side effects. Good catch, documented clearly in the script's own comment.

No security concerns; this is a build/publish pipeline change only and doesn't touch any trust boundary. Test coverage looks appropriate for the fix's scope.