Conversation
…t tsconfig types The Windows WSL job is the critical path of every CI run (589 to 752 s). Its checkout sits on the Windows drive, which WSL reaches over 9P, and writing node_modules there is what makes npm ci take about three minutes where the Linux job takes 23 s. The step now copies the tree onto the distro's ext4 filesystem before installing and building, as Microsoft's WSL guidance recommends for I/O-heavy work. The e2e job downloaded the full Chromium build (about 165 MB) on every run, but a headless run with no channel launches chromium-headless-shell and never opens it. `--only-shell` skips that download. Every tsconfig now lists the @types packages it uses (node, bun, vite/client, dom-speech-recognition) instead of relying on TypeScript auto-including everything under node_modules/@types. On TypeScript 5.9 this is a no-op: identical diagnostics across all 48 projects and byte-identical emitted .d.ts files. It is a prerequisite for TypeScript 7, which drops the auto-inclusion; with these lists the Go compiler passes all 48 projects, so that upgrade becomes a version bump once TypeDoc supports it. Two cache-based approaches were evaluated and rejected: an npm cache for the WSL job (npm ci is slow there because of 9P, not downloads, and a prefix-restored cache grows without bound) and a Playwright browser cache (Playwright's docs advise against it; the download is under 10 s).
Contributor
PreviewPreview deployments for this PR have been cleaned up. |
@modelcontextprotocol/ext-apps
@modelcontextprotocol/server-basic-preact
@modelcontextprotocol/server-basic-react
@modelcontextprotocol/server-basic-solid
@modelcontextprotocol/server-basic-svelte
@modelcontextprotocol/server-basic-vanillajs
@modelcontextprotocol/server-basic-vue
@modelcontextprotocol/server-budget-allocator
@modelcontextprotocol/server-cohort-heatmap
@modelcontextprotocol/server-customer-segmentation
@modelcontextprotocol/server-debug
@modelcontextprotocol/server-lazy-auth
@modelcontextprotocol/server-map
@modelcontextprotocol/server-pdf
@modelcontextprotocol/server-scenario-modeler
@modelcontextprotocol/server-shadertoy
@modelcontextprotocol/server-sheet-music
@modelcontextprotocol/server-system-monitor
@modelcontextprotocol/server-threejs
@modelcontextprotocol/server-transcript
@modelcontextprotocol/server-video-resource
@modelcontextprotocol/server-wiki-explorer
commit: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three changes, each measured or verified before landing; two cache-based approaches were tried first and dropped (details at the end).
WSL job on ext4.
Build (Windows WSL)is the critical path of every CI run (589 to 752 s across the last six). Its checkout is on the Windows drive, which WSL reaches over 9P;npm cithere takes about 3 minutes against 23 s on the Linux job with the same lockfile. The step now copies the tree onto the distro's ext4 filesystem first, which is what Microsoft's WSL docs recommend for anything I/O heavy. Everything the job does (install, build, examples, tests, prettier) runs on the copy; nothing downstream reads the original.--only-shellfor Playwright. The e2e job downloaded the full Chromium build (about 165 MB) on every run, but a headless run with no channel launcheschromium-headless-shelland never opens it (PW_CHANNELis unset in CI). Same command, one flag.Explicit
typesin every tsconfig. 48 tsconfigs now list the@typespackages they use (node,bun,vite/client,dom-speech-recognition) instead of relying on TypeScript auto-including everything undernode_modules/@types. On TypeScript 5.9 this is a no-op, checked project by project: identical exit codes and diagnostics across all 48, no source file dropped from any program, and byte-identical emitted.d.tsfor the root and the 23 example servers. It is the prerequisite for TypeScript 7 (the Go compiler), which drops auto-inclusion: on main the TS 7 compiler fails 41 of 48 projects on exactly that, and with these lists it passes all 48, 7 to 8× faster per project. The upgrade itself waits on TypeDoc, which still needs the TS 5/6 compiler API (TypeStrong/typedoc#3098, maintainer expects support around TS 7.1). Note for that future flip: TS 7 emits a slightly differentapp-bridge.d.ts, so it should be a version bump for checking first, with declaration emit staying on the old compiler until the output is reviewed.Rejected. An npm cache for the WSL job (
actions/cacheon a Windows-side dir): mechanically sound, butnpm ciis slow there because of 9P, not downloads (tarball caching is worth 7 to 13 s elsewhere), and a prefix-restored cache grows without bound under npm's no-prune cacache. A Playwright browser cache: Playwright's own CI docs say not to, and the measured download is 9.6 s on a job 100 s or more off the critical path.