fix: declare commander as a direct dependency (#873)#1373
Open
NishchayMahor wants to merge 1 commit into
Open
Conversation
The top-level package ships cli/build/cli.js as its bin, and that file imports commander at runtime. commander was only listed as a dep of the sibling inspector-cli workspace, so it was resolving by npm hoisting. pnpm and other strict installers don't hoist, so the bin failed with 'Cannot find package commander'. Adding commander to the top-level dependencies makes the bin work under any installer.
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.
Closes #873.
What's wrong
The top-level `@modelcontextprotocol/inspector` package ships `cli/build/cli.js` as its `bin` (it's in the published `files` list). That file imports `commander` at runtime, but `commander` was only declared on the sibling `@modelcontextprotocol/inspector-cli` workspace package.
Under npm, the package resolves fine because npm flat-hoists `commander` to the top of `node_modules`. Under pnpm and other strict installers there's no hoisting, so users hit:
```
Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'commander' imported from
node_modules/.pnpm/@modelcontextprotocol+inspector@0.21.2_.../node_modules/@modelcontextprotocol/inspector/cli/build/cli.js
```
What this PR does
Adds `"commander": "^13.1.0"` to the top-level `package.json` so the published bin script can resolve its runtime imports regardless of which installer (or hoisting strategy) the user has chosen. This is Option 1 from the issue, kept narrow so the rest of the publishing layout is unchanged.
I audited the rest of `cli/src/*.ts` for external imports. The only non-Node runtime packages it pulls are:
`express` is in `cli/package.json` but only used in `cli/tests/helpers/test-server-http.ts`, so it doesn't need to be hoisted to the published top-level.
Lockfile
I left `package-lock.json` alone in this PR because the project's CI runs `npm install --no-package-lock` and a fresh `npm install --package-lock-only` on my machine produced a noisy diff (~60 unrelated `peer: true` toggles from npm normalising my local resolution). Happy to fold a clean lockfile bump into the same commit if you'd prefer, just let me know.