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

fix: address Copilot review round 1 — move the Storybook optimizeDeps into a tested helper

Browse source 
The storybook project's optimizeDeps now comes from
`getStorybookOptimizeDeps()` in `vite-base-config.ts`, beside the dev-server
helper it mirrors, so the `force` flag and the base include/exclude it carries
are asserted by `vite-base-config.test.ts` rather than living only in an
inline object a config refactor could drop.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PsmUAZ6aLUAFqenjJKSSRp
Signed-off-by: cliffhall <cliff@futurescale.com>
This commit is contained in:
cliffhall 2026-09-12 19:24:44 -04:00
commit 86e6774a9a
1 changed files with 62 additions and 21 deletions
Download patch file Download diff file Expand all files Collapse all files

35
clients/web/server/vite-base-config.ts
View file

@ -59,14 +59,43 @@ export function getViteBaseConfig() {
// That was one instance of a class, not the class: any package a story
// or component starts importing after the cache was written is
// discovered the same way, and pinning each one here would chase the
// symptom. The `storybook` project in `vite.config.ts` now sets
// `optimizeDeps.force` so every run re-scans the story entries up front
// (#2340); this entry stays as the explicit include it always was.
// symptom. `getStorybookOptimizeDeps` below adds `force` so every run
// re-scans the story entries up front (#2340); this entry stays as the
// explicit include it always was.
include: ["@modelcontextprotocol/client"],
},
};
}
/**
* Storybook (browser Vitest project) optimizeDeps: the base set, re-bundled
* on every run instead of read from the cache (#2340).
*
* Vite keys that cache on the lockfile and on the config, never on what the
* story graph imports, so a cached bundle stays "valid" after a story or
* component gains an import of a package that is already installed. With a
* valid cache Vite skips the scan, and the first request for the new package
* re-runs the optimizer mid-run: the shared chunks are rewritten, the `?v=`
* browser hash is bumped, and Vite sends a `full-reload` that the Vitest
* tester iframes do not act on. The `@storybook/react` renderer already loaded
* in a live iframe still holds the old hash for its lazy
* `import("@storybook/react-dom-shim")`, so every story that iframe renders
* from then on fails with "Failed to fetch dynamically imported module" — and
* the next run is green, because the cache has caught up. `force` discards the
* cache up front so the scanner crawls every story entry before the browser
* opens: the same cold path CI takes on every PR. Cost: ~0.8s per run.
*
* Spread from `getViteBaseConfig()` rather than left to Vitest's project merge
* so the include/exclude the base set carries are the helper's own claim, and
* tested as such.
*/
export function getStorybookOptimizeDeps() {
return {
...getViteBaseConfig().optimizeDeps,
force: true,
};
}
/**
* Dev-server optimizeDeps: rebuild from scratch each launch — no stale
* pre-bundles carried across restarts (avoids 504 Outdated Optimize Dep).