build: require Vite DevTools 0.7.6 and drop the DF8111 workaround

[morinokami]

Vite DevTools 0.7.6 declares Vite's /@id/{specifier} client-module resolution before any plugin's devtools.setup() runs (vitejs/devtools#582). Up to 0.7.5 it did so only in initHub(), after the setup hooks. Each Astro dock that names its renderer by the bare specifier astro-devtools/client therefore warned DF8111 ("the script will fail to load") about a script that loads fine, and setup() wrote the template into staticConfig.dock itself to silence that. This PR bumps the devtools catalog to 0.7.6 and removes the workaround.

• Catalog: the six @vitejs/devtools-* entries go from 0.7.5 to 0.7.6. The devframe family stays at 1.0.0, the same version upstream's v0.7.6 lockfile resolves. devframe 1.1.0, released the same day, is left for a separate bump.
• Workaround: removed from setup() in src/vite-plugin.ts.
• Peer floor: @vitejs/devtools and @vitejs/devtools-kit now require ^0.7.6. Without the workaround, 0.7.5 prints DF8111 once per custom-render dock, five warnings in all.
• e2e: the test that asserts no [DF8111] in the server log is renamed. Its old title said the integration declares the resolution; the test now guards the peer floor.

Other changes in 0.7.6

None of them change the Astro panels, the MCP endpoint, or the connection flow the skill documents.

• Build injection (feat(core): support devtools injection in builds vitejs/devtools#580) is opt-in (build.injection, default false), and the integration does nothing outside astro dev. In dev, the injection plugin behaves as before.
• Project paths and Vite+ build commands (fix: respect project paths and Vite+ build commands vitejs/devtools#581) and the tokenized Vitest UI URL (fix(vitest): embed the tokenized Vitest UI URL vitejs/devtools#588) only change Vite DevTools' own Oxc, Rolldown and Vitest panels. The kit only gains an export, and this package uses the kit for types only.
• Discovery registration (fix: register Vite DevTools for devframe discovery vitejs/devtools#579): on its first request, the hub now writes ~/.devframe/instances/<pid>-<port>.json. The record has id: "vite-devtools", basePath: "/__devtools/" and mcp: null, because the integration keeps the hub's MCP route off. The MCP bridge does not register, so nothing collides on that file name, and /__astro-devtools/__connection.json is unchanged. This has two side effects:
  • Stopping astro dev with SIGINT (Ctrl+C) leaves the record behind, because Vite closes the server only on SIGTERM and Astro's dev server has no SIGINT handler. The next reader deletes it when its liveness probe fails, and astro dev stop (SIGTERM) removes it.
  • With devframe 1.1.0, devframe connect --port <n> --base /__astro-devtools/ skips its listing probe for a port that already has a record. The hub's record therefore hides the bridge from that listing, although tool calls still reach it. The skill does not use devframe connect.

Verification

• vp run ready passes: build (including the playground's astro build), sync, check, knip, publint, the 373 unit tests, and the 88 story tests.
• vp run playground#e2e: 51 passed.
• Negative control: on 0.7.5 with the workaround removed, the server log shows five DF8111 warnings (overview, islands, routes, actions, config), and the renamed e2e test fails. Back on 0.7.6, it passes.
• The discovery record was checked in a playground dev server with DEVFRAME_INSTANCES_DIR pointed at a temporary directory. The record was written on the first hub request and was still there after SIGINT. The e2e runs stop the server with SIGTERM, and they left no record in ~/.devframe/instances.
• The devframe connect behavior comes from reading devframe 1.1.0's source; it was not run.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DLDVYeDh6abCj8w9TxSXUQ

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/morinokami/astro-devtools@11

commit: 2ddb1f7