Create v2 publishing pipeline for main.yml (single inspector package)

[cliffhall]

Summary

When v2/main eventually replaces main, the release/publish pipeline in .github/workflows/main.yml has to change. v2 no longer publishes the separate @modelcontextprotocol/inspector-client / -server / -cli packages — it ships a single package, @modelcontextprotocol/inspector, that bundles the launcher, web, cli, and tui builds. We need to investigate exactly what the publishing workflow should look like on the new architecture.

Background

• v1 main.yml (current main branch) has a publish job that runs npm run publish-all = npm publish --workspaces --access public && npm publish --access public. That relies on the v1 npm workspaces (client, server, cli) to publish four packages. It also has a publish-github-container-registry job (GHCR Docker image). Both are gated on github.event_name == 'release'.
• v2 main.yml (this branch) has no publish job at all — it only runs CI (validate → coverage gate → smokes → Storybook). Publishing was never ported.
• v2 is not an npm workspace. Each clients/* keeps its own package.json/node_modules; the root postinstall cascades installs. The published root package @modelcontextprotocol/inspector (v2.0.0) declares files = the launcher/web/cli/tui build outputs + install-clients.mjs, and bin = mcp-inspector. So npm run publish-all / --workspaces no longer applies.

What to investigate / decide

1. Single-package publish for v2. Design the release job that publishes just @modelcontextprotocol/inspector. Confirm files/prepack/bin produce a correct, installable tarball (npm pack dry-run), including that the postinstall client cascade is a no-op for end users (it exits early under node_modules, and only build/ ships).
2. Publish core/ as its own package? core/ is currently consumed via the @inspector/core Vite alias and has no package.json. Investigate giving it its own publishable package (e.g. @modelcontextprotocol/inspector-core) so third parties can build on the shared InspectorClient/state/react/auth/mcp code. This needs: a core/package.json (name, version, exports map, types), a build step (currently it's only ever bundled by consumers, never built standalone), decoupling from the Vite alias for external consumers, and versioning strategy vs. the main package.
3. Version consistency. v1 has check-version / update-version scripts across workspaces. Decide the v2 equivalent (single version, or main + core in lockstep / independent).
4. GHCR Docker image. Confirm whether the container publish job carries over and what it should build (launcher entrypoint).
5. Provenance / release environment. Port the environment: release, id-token: write, and the --provenance TODO now that the repo is public.

Tracking issue for the v2 publish pipeline.

• Packaging correctness + pack:verify + single-source version — v2 single-package publish bundle correctness + pack:verify #1645
• main.yml release job (publish, provenance, GHCR, version/tag flow) — Wire the v2 single-package publish/release job into main.yml (at the v2→main cutover) #1640
• GHCR Docker image - Decide + wire v2 Docker image (GHCR) — v2 has no Dockerfile #1646
• Standalone core package — deferred

Acceptance

• A documented plan (and/or draft workflow changes) for the v2 publish pipeline on main.yml, covering: single inspector package publish, the decision + mechanics for an optional standalone core package, version consistency, GHCR, and provenance.

Note: this targets the eventual v2/main → main cutover; the workflow edit lands when v2 replaces v1.

[cliffhall]

Measured package size (fresh npm run build + npm pack --dry-run)

The single v2 @modelcontextprotocol/inspector package, as files is currently configured:

	Size
Compressed .tgz (npm download)	~1.5 MB
Unpacked (installed on disk)	~6.6 MB
File count	25

Unpacked weight by area:

Area	Size	Notes
clients/tui/build	4.09 MB	dominated by a bundled undici copy (1.9 MB of that is a .js.map)
clients/web/dist	1.62 MB	browser SPA (1.4 MB JS + 0.2 MB CSS)
clients/cli/build	0.88 MB	0.26 MB code + 0.66 MB source map
clients/launcher/build	~3 KB	thin mcp-inspector bin dispatcher

Small by npm standards, and a big simplification over v1's ~4 separate packages. Two packaging issues surfaced while measuring that the release-workflow work should resolve:

1. Source maps are ~half the payload

.js.map files account for 3.29 MB of the 6.6 MB unpacked (the tui undici map alone is ~1.8 MB). They're a debugging aid, not needed at runtime. Excluding maps from the published files (or setting each client bundler to not emit/ship them) would roughly halve the install to ~3.3 MB. Decide whether published builds should carry source maps at all.

2. clients/web/build is listed in files but is absent from the tarball

The root npm run build runs build:web (Vite → clients/web/dist) but not build:web:runner (→ clients/web/build, the Hono prod-server runner). So clients/web/build — which files declares — is either not produced by the release build or is served stale. The smoke:web path builds dist on demand, which masks this locally. The publish-pipeline investigation should confirm exactly what the prod --web server needs at runtime and make the release build produce it deterministically (and if web/build, ~3 MB on disk incl. another undici map, does get included, the total grows accordingly).

[cliffhall]

Decisions — scope for the v2 publish pipeline

Locking in the approach before implementation:

1. One package, one version. Ship a single @modelcontextprotocol/inspector package containing the launcher + web + cli + tui builds, versioned with a single version number. No standalone core package for now — that's deferred (can be revisited later if there's demand for third parties to build on the shared core).
2. Drop source maps from the published bundle. .js.map files are ~half the unpacked payload and aren't needed at runtime; they'll be excluded from what gets published (roughly halving the install to ~3.3 MB).
3. Make clients/web/build correct. Ensure the prod --web server runner (clients/web/build) is actually produced by the release build and contains what prod --web needs at runtime — it's declared in files today but not built by the root build.
4. Add a bundle-and-verify script. We've been bitten before by things working in --dev locally but breaking under the real published package (npx @modelcontextprotocol/inspector …) due to path resolution differences. So this work includes a script that builds the exact tarball npm would publish, installs it into a clean throwaway location, and runs the real mcp-inspector bin (web/cli/tui) against it — catching path/packaging failures that dev mode masks, before we ever publish.

Implementation happens on v2/main. Actual main.yml release-job wiring still lands at the v2/main → main cutover, but the packaging, source-map trimming, web/build fix, and the local pack-and-test script land now.

[cliffhall]

Scope split. PR #1637 delivers the packaging correctness half of this issue: single-package tarball, source maps dropped, the clients/web/build packlist fix, single-source version from the root package.json, and the npm run pack:verify publish smoke. It references this issue (Refs #1636) but does not close it.

Remaining scope stays here / is tracked separately:

• main.yml release-job wiring → split into Wire the v2 single-package publish/release job into main.yml (at the v2→main cutover) #1640 (release-gated npm publish behind pack:verify, provenance, GHCR decision, version-bump/tag flow). Lands at the v2/main → main cutover.
• Standalone core package → still deferred; remains under this issue.

So keep #1636 open after #1637 merges.