Repository navigation
npx-migration: link the staged bundle's bin so npx resolves the local override - #26
Merged
Merged
Conversation
… npx resolves the local override (comms-hl7y)
The frozen marketplace launches `npx -y @codeforbreakfast/commy-mcp` with
cwd=${CLAUDE_PLUGIN_ROOT}, and resolves the bundle from the local
node_modules override (zero registry hops). But npx resolves a package's
*bin*, and stageMarketplace only copied the assembled package — it never
created the node_modules/.bin/commy-mcp link an `npm install` makes, and
left server.js non-executable. So npx fell through to a PATH lookup and
died `commy-mcp: command not found`; a seat installed from the local
override never booted the server.
stageMarketplace now recreates that link (relative, so it survives the
atomic rename into the fixed path) and marks the entry executable,
mirroring an install. The published-package path was unaffected — a
registry install links the bin itself — only the local-override path
broke.
verifyBoots was blind to this: it launched `node .../server.js` directly,
bypassing the bin resolution. It now launches through the bin entry
(node_modules/.bin/<name>, the exact file npx execs via its shebang), so
the boot smoke test covers a missing/broken bin link or a non-executable
entry as well as a bundle that fails to load.
GraemeF
added a commit
that referenced
this pull request
Jun 14, 2026
First release carrying the npx delivery migration (#21–#26): the MCP server and PreToolUse hook now run on node, the plugin launches via `npx @codeforbreakfast/commy-mcp`, and the publishable `@codeforbreakfast/commy-mcp` npm package is assembled by `bun run pack:npm`. This is the tag the github-source marketplace cutover (comms-taa3) pins to. **Patch bump** — npx is infrastructure; no new tool, userConfig key, or env var. Bumps the six version sites + `clients/hermes/uv.lock` in lockstep (0.11.2 → 0.11.3): - `clients/claude-code/.claude-plugin/plugin.json` - `clients/claude-code/package.json` - `packages/mcp/package.json` - `packages/mcp/mcp-server.ts` (`PLUGIN_VERSION`) - `clients/hermes/pyproject.toml` - `clients/hermes/commy/plugin.yaml` - `clients/hermes/uv.lock`
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The frozen marketplace's
.mcp.jsonlaunchesnpx -y @codeforbreakfast/commy-mcpwithcwd=${CLAUDE_PLUGIN_ROOT}, designed to resolve the bundle from a localnode_modulesoverride with zero registry hops. Butnpxresolves a package's bin, andstageMarketplaceonly copied the assembled package intonode_modules/@codeforbreakfast/commy-mcp/— it never created thenode_modules/.bin/commy-mcpsymlink thatnpm installmakes, and leftserver.jsnon-executable.Result:
npx @codeforbreakfast/commy-mcpfrom the plugin dir falls through to a PATH lookup and dies withsh: commy-mcp: command not found, so a plugin installed from the local-override marketplace never boots its server. The published-package path was unaffected — a registry install links the bin itself; only the local-override path broke.The boot smoke test missed it because
verifyBootslaunchednode .../server.jsdirectly, bypassing the bin resolution entirely.Fix
stageMarketplacenow recreates the.binlink (relative, so it survivesatomicSwaprenaming the staging dir into the fixed path) and marks the entry executable, mirroring whatnpm installdoes. Bin names follow npm's normalisation (stringbin→ unscoped package name).verifyBootsnow launches the staged bundle through its bin entry (node_modules/.bin/<name>, the exact file npx resolves and execs via its shebang), so the smoke test covers a missing/broken bin link or a non-executable entry as well as a bundle that fails to load.Verification
Confirmed end-to-end through the real
npxlauncher against a freshly staged tree: npx resolves the local override (node .../node_modules/.bin/commy-mcp, no registry hop), boots under node, answers the MCP initialize handshake, and exits cleanly on stdin EOF (no orphaned process). The published registry path was independently confirmed working too.