fix(vitest): embed the tokenized Vitest UI URL

[zahidzorbaz]

Description

With Vitest 5 the Vitest UI launcher embedded Vitest's 403 "requires authentication" page instead of the UI. Since vitest-dev/vitest#10583, /__vitest__/ needs the API token Vitest prints on startup (UI started at …/__vitest__/?token=…). The launcher embedded the bare URL, and its readiness probe accepted any status below 500, so the 403 counted as ready.

This PR:

• adds packages/vitest/src/node/ui-url.ts:
  • resolveVitestUiUrl(url, output) reads the token from the UI started at line (ANSI stripped with node:util's stripVTControlCharacters) and returns the launcher's URL with ?token=. It returns the URL unchanged when the printed URL has no token (Vitest < 5), or undefined if the line hasn't been printed yet.
  • waitForVitestUi(url, timeout, getOutput) polls the tokenized URL (plain URL until the line shows up) with redirect: 'manual', and treats only 2xx/3xx as ready. Vitest answers a valid ?token= with 302 plus the auth cookie.
• serve.onReady reads the session's output (session.buffer) and returns the tokenized URL as the iframe URL, so the browser's first request sets the cookie and gets redirected to the UI.
• updates docs/errors/VTDT0002.md (cause and source) to match.

Linked Issues

Fixes #585

Additional context

• Tests: packages/vitest/src/node/__tests__/ui-url.test.ts covers the parser (no line yet, ANSI-colored Vitest 5 line, Vitest < 5 line without a token) and the readiness loop against a local server that behaves like Vitest 5's vitestUiAuth middleware. The 403-only case would have counted as ready under the old status < 500 check.
• Checked against a real Vitest 5.0.0 UI (outside DevTools): waitForVitestUi returned http://localhost:<port>/__vitest__/?token=…. Requesting it gave 302 + vitest-ui-token cookie, and following the redirect with the cookie returned 200 with the UI HTML.
• Not verified in a browser. Vitest sets the cookie SameSite=Strict, and the launcher hard-codes localhost. If DevTools is opened on http://127.0.0.1:<vite port>, the iframe is cross-site and the browser may refuse the cookie. The UI would then get a 403 on the redirected request even with the token. Using the DevTools page's hostname for the iframe would avoid that. Out of scope here.
• The tokenized URL is kept in the dock entry, which is visible to DevTools clients. Those clients can already run terminal commands, so this adds no new capability, but the token now leaves the terminal output.
• Gates on Windows 11 / Node 24.21: pnpm lint, pnpm typecheck and pnpm build pass. pnpm test passes except two packages/ui bytesToHumanSize cases ('1,5' vs '1.5'). They fail the same way on a clean main here because of the machine's tr-TR locale, and are unrelated.

🤖 Generated with Claude Code

[pkg-pr-new]

Open in StackBlitz

@vitejs/devtools

npm i https://pkg.pr.new/@vitejs/devtools@588

@vitejs/devtools-kit

npm i https://pkg.pr.new/@vitejs/devtools-kit@588

@vitejs/devtools-oxc

npm i https://pkg.pr.new/@vitejs/devtools-oxc@588

@vitejs/devtools-rolldown

npm i https://pkg.pr.new/@vitejs/devtools-rolldown@588

@vitejs/devtools-vite

npm i https://pkg.pr.new/@vitejs/devtools-vite@588

@vitejs/devtools-vitest

npm i https://pkg.pr.new/@vitejs/devtools-vitest@588

commit: 05392df