modelcontextprotocol/inspector
Watch
1
0
Fork
You've already forked inspector
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 2

docs: correct the dependency-classification claims

Browse source 
Copilot review round 2, four findings, all factual errors in the docs added by
the previous commit:

- `yaml` is in the root `dependencies`, not `devDependencies`, and its only
  importer is `test-servers/src/load-config.ts` — not `core/` or the root
  tooling, as the `vitest.shared.mts` comment claimed.
- The rule as written told a reader to put anything reached through root-owned
  code — `core/` included — in `devDependencies`. That is wrong and would break
  the published package silently: the client builds externalize npm packages, so
  a published install resolves them from the root manifest, where
  devDependencies are absent. Placement (which manifest) and classification
  (which section) are now stated as separate questions, the second following
  from who consumes the package at runtime.

`yaml`'s runtime classification is left alone and called out instead: moving it
changes what ships, which is not a docs change.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HDdo1rNRVQnVRRdsqSrvG3
This commit is contained in:
cliffhall 2026-08-11 09:35:04 -04:00
commit 5a3a3436ea
1 changed files with 20 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

3
.github/copilot-instructions.md vendored
View file

@ -76,7 +76,8 @@ Both exist and do different jobs. Theme files (`src/theme/<Component>.ts`) custo
- **The MCP SDK packages (`@modelcontextprotocol/client`, `core`, `server`, `server-legacy`, `ext-apps`) belong in the root `package.json` only.** Adding one to a `clients/*/package.json` is a review finding: Node resolution walks up, so the root install already serves every client, and a per-client entry installs a second copy that drifts (it produced two versions of `ext-apps`, and of the transitive v1 SDK, at once — #1970) and reintroduces the duplicate-copy failure `vitest.shared.mts` has a `dedupe` workaround for.
- **The v1 `@modelcontextprotocol/sdk` is not a dependency of this repo** and must not become one. It is a peer of `ext-apps`, present in lock files only.
- Dependencies used only by **root-owned code with no manifest** (`test-servers/src`, `core/`) go in the root `devDependencies` and are aliased to the **repo root** in `vitest.shared.mts` — as `express` and `yaml` are — not to `<client>/node_modules` like the other pins there.
- Dependencies reached only through **root-owned code with no manifest** (`test-servers/src`, `core/`) are declared at the root and aliased to the **repo root** in `vitest.shared.mts` — as `express` and `yaml` are — not to `<client>/node_modules` like the other pins there.
- **Which section is a separate question from which manifest.** A package `core/` imports at runtime must be in root **`dependencies`**: client builds externalize npm packages, so a published install resolves them from the root manifest and devDependencies are absent there. Only test/build-only packages (`express`) belong in `devDependencies`. Flag a runtime `core/` import added to `devDependencies` — it passes every local check and breaks the published package.
## Tests and the coverage gate