Repository navigation
Create v2 publishing pipeline for main.yml (single inspector package) #1636
Description
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(currentmainbranch) has apublishjob that runsnpm 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 apublish-github-container-registryjob (GHCR Docker image). Both are gated ongithub.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 ownpackage.json/node_modules; the rootpostinstallcascades installs. The published root package@modelcontextprotocol/inspector(v2.0.0) declaresfiles= the launcher/web/cli/tui build outputs +install-clients.mjs, andbin=mcp-inspector. Sonpm run publish-all/--workspacesno longer applies.
What to investigate / decide
- Single-package publish for v2. Design the release job that publishes just
@modelcontextprotocol/inspector. Confirmfiles/prepack/binproduce a correct, installable tarball (npm packdry-run), including that thepostinstallclient cascade is a no-op for end users (it exits early undernode_modules, and onlybuild/ships). - Publish
core/as its own package?core/is currently consumed via the@inspector/coreVite alias and has nopackage.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: acore/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. - Version consistency. v1 has
check-version/update-versionscripts across workspaces. Decide the v2 equivalent (single version, or main + core in lockstep / independent). - GHCR Docker image. Confirm whether the container publish job carries over and what it should build (launcher entrypoint).
- Provenance / release environment. Port the
environment: release,id-token: write, and the--provenanceTODO 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.ymlrelease 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— deferredcorepackage
Acceptance
- A documented plan (and/or draft workflow changes) for the v2 publish pipeline on
main.yml, covering: singleinspectorpackage publish, the decision + mechanics for an optional standalonecorepackage, version consistency, GHCR, and provenance.
Note: this targets the eventual v2/main → main cutover; the workflow edit lands when v2 replaces v1.
Activity
cliffhall commentedon Jul 10, 2026
Measured package size (fresh
npm run build+npm pack --dry-run)The single v2
@modelcontextprotocol/inspectorpackage, asfilesis currently configured:.tgz(npm download)Unpacked weight by area:
clients/tui/buildundicicopy (1.9 MB of that is a.js.map)clients/web/distclients/cli/buildclients/launcher/buildmcp-inspectorbin dispatcherSmall 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.mapfiles account for 3.29 MB of the 6.6 MB unpacked (the tuiundicimap alone is ~1.8 MB). They're a debugging aid, not needed at runtime. Excluding maps from the publishedfiles(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/buildis listed infilesbut is absent from the tarballThe root
npm run buildrunsbuild:web(Vite →clients/web/dist) but notbuild:web:runner(→clients/web/build, the Hono prod-server runner). Soclients/web/build— whichfilesdeclares — is either not produced by the release build or is served stale. Thesmoke:webpath buildsdiston demand, which masks this locally. The publish-pipeline investigation should confirm exactly what the prod--webserver needs at runtime and make the release build produce it deterministically (and ifweb/build, ~3 MB on disk incl. another undici map, does get included, the total grows accordingly).cliffhall commentedon Jul 10, 2026
Decisions — scope for the v2 publish pipeline
Locking in the approach before implementation:
@modelcontextprotocol/inspectorpackage containing the launcher + web + cli + tui builds, versioned with a single version number. No standalonecorepackage for now — that's deferred (can be revisited later if there's demand for third parties to build on the shared core)..js.mapfiles 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).clients/web/buildcorrect. Ensure the prod--webserver runner (clients/web/build) is actually produced by the release build and contains what prod--webneeds at runtime — it's declared infilestoday but not built by the rootbuild.--devlocally 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 realmcp-inspectorbin (web/cli/tui) against it — catching path/packaging failures that dev mode masks, before we ever publish.Implementation happens on
v2/main. Actualmain.ymlrelease-job wiring still lands at thev2/main→maincutover, but the packaging, source-map trimming,web/buildfix, and the local pack-and-test script land now.cliffhall commentedon Jul 10, 2026
Scope split. PR #1637 delivers the packaging correctness half of this issue: single-package tarball, source maps dropped, the
clients/web/buildpacklist fix, single-source version from the rootpackage.json, and thenpm run pack:verifypublish smoke. It references this issue (Refs #1636) but does not close it.Remaining scope stays here / is tracked separately:
main.ymlrelease-job wiring → split into Wire the v2 single-package publish/release job into main.yml (at the v2→main cutover) #1640 (release-gatednpm publishbehindpack:verify, provenance, GHCR decision, version-bump/tag flow). Lands at thev2/main→maincutover.corepackage → still deferred; remains under this issue.So keep #1636 open after #1637 merges.
[-]Investigate v2 publishing pipeline for main.yml (single inspector package + optional standalone core package)[/-][+]Create v2 publishing pipeline for main.yml (single inspector package + optional standalone core package)[/+][-]Create v2 publishing pipeline for main.yml (single inspector package + optional standalone core package)[/-][+]Create v2 publishing pipeline for main.yml (single inspector package)[/+]cliffhall commentedon Jul 11, 2026
v2 publishing pipeline complete — all children merged into v2/main:
The standalone core package was deferred indefinitely (no image needed). Closing.