Merge pull request #2361 from modelcontextprotocol/v2/chore/2359-sdk-watch-example

chore: refresh the stale ext-apps example in the sdk-watch comments
This commit is contained in:
Cliff Hall 2026-09-13 20:13:25 -04:00 • committed by GitHub
commit 153ee7dd15
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
2 changed files with 11 additions and 10 deletions

View file

@ -130,7 +130,7 @@ The board write needs `organization projects: write`, which `GITHUB_TOKEN` canno
**`.github/workflows/sdk-watch.yml` → `scripts/sdk-watch.mjs` runs nightly (#1063) and files one issue per MCP SDK release we are behind**, labeled `v2` + `chore` + `dependencies`. It is not a Dependabot replacement — it exists because SDK churn, OAuth especially, was being tracked by habit rather than by mechanism — but it obeys the same rule as the two above: **it files an issue, never a PR.**
- **Two upstreams, two issues.** `client`/`core`/`server`/`server-legacy` ship from `modelcontextprotocol/typescript-sdk` in lockstep and share one issue; `ext-apps` ships from its own repo and gets its own. A fifth `@modelcontextprotocol/*` package added to the root manifest and not added to `SDK_GROUPS` **fails the sweep loudly** rather than going unwatched — that guard is the point, since a hardcoded group table is otherwise a silent blind spot.
- **It compares the INSTALLED version, not the declared range.** The four SDK packages are pinned exactly, so the two agree for them; `ext-apps` is a caret range whose lockfile already resolves higher, and comparing the declared string would file an issue for a bump `npm install` has already taken.
- **It compares the INSTALLED version, not the declared range.** The four SDK packages are pinned exactly, so the two agree for them; `ext-apps` is a caret range, so its lockfile can already resolve higher than the manifest's floor, and comparing the declared string would file an issue for a bump `npm install` has already taken.
- **The target is the LOWEST `latest` across a group — the version the whole group has reached — not the highest.** npm publishes a lockstep release one package at a time, so a sweep landing mid-publish sees one package ahead of its three siblings. Targeting the highest would name a version three of them do not have _and_ write a marker that suppresses the real filing once the publication completes, so the release would never be tracked at all. Taking the minimum keeps the issue actionable and lets the completed release file its own.
- **It never boards, like the monthly sweep** — no `PROJECT_TOKEN` exists in this org — so the issue arrives labeled and milestoned and `/issue-triage` places it.
- **It never closes an issue either.** A further release files its own issue and leaves a **supersession comment** on the older one; closing is a maintainer act, since the card may already have moved. An issue closed for the same target keeps suppressing it, so a maintainer's "not planned" is not re-argued nightly.

View file

@ -27,11 +27,12 @@
// 2. **Compare the INSTALLED version, not the declared range.** #1063 phrases
// the check as "is the current version > than the one we have in our
// package.json", which is exact today only because the four SDK packages
// are pinned exactly. `ext-apps` is a caret range (`^1.7.4`) whose lockfile
// already resolves higher, so comparing against the declared string would
// file an issue for a bump `npm install` has already taken. The declared
// range is still reported — it is what says whether the fix is a manifest
// edit or a lockfile refresh — but the comparison is against the lockfile.
// are pinned exactly. `ext-apps` is a caret range, so its lockfile can
// already resolve higher than the manifest's floor, and comparing against
// the declared string would file an issue for a bump `npm install` has
// already taken. The declared range is still reported — it is what says
// whether the fix is a manifest edit or a lockfile refresh — but the
// comparison is against the lockfile.
// 3. **A new SDK package must not be watched silently by nobody.** The group
// table is a hardcoded list, so a fifth `@modelcontextprotocol/*` package
// added to the root manifest would never be checked and nothing would say
@ -352,10 +353,10 @@ const cell = (value) => String(value).replace(/\|/g, "\\|");
* ⚠️ Not every bump is a manifest edit, and saying so unconditionally was wrong
* for the very case this script exists to handle separately (Copilot). The four
* `typescript-sdk` packages are pinned **exactly**, so any new version needs the
* manifest changed. `ext-apps` is a **range** (`^1.7.4`), so a 1.8.0 target is
* already satisfied by what `package.json` says and only `npm install` is needed
* — telling a maintainer to edit the manifest there sends them to change a line
* that is already correct.
* manifest changed. `ext-apps` is a caret **range**, so a target that is only a
* patch or minor ahead within the same major is already satisfied by what
* `package.json` says and only `npm install` is needed — telling a maintainer to
* edit the manifest there sends them to change a line that is already correct.
*
* A row whose declared value is not a parseable range (an unparsed dependency,
* or the `(undeclared)` placeholder) counts as needing the edit: that is the