fix(docker): work around npm 10.x's arborist crash in the TS builders - #4787
Open
AmirF194 wants to merge 1 commit into
Open
fix(docker): work around npm 10.x's arborist crash in the TS builders#4787AmirF194 wants to merge 1 commit into
AmirF194 wants to merge 1 commit into
Conversation
The builder stage's npm install crashes on all four TS servers with "Cannot read properties of null (reading 'edgesOut')", reproduced on unmodified main with a fully cleared build cache. Bisected past the issue's own finding: plain vitest alone triggers it, in an otherwise empty package.json, so it isn't specific to this repo's dependency graph. It's an npm 10.x arborist bug; npm 11.19.1 resolves the same package.json with no errors and no extra flags. release.yml already upgrades past this for a different reason (OIDC trusted publishing needs npm >=11.5.1, and node 22's bundled npm is 10.x). Do the same in each builder stage before npm install. Confirmed npm 10.9.x in the release stage still reads a lockfile that npm 11 wrote with npm ci, so nothing downstream needs to change. Verified with docker buildx build --no-cache for all four servers: fails on unmodified main with the issue's exact error, builds clean on this branch. Ran each built image through a real MCP initialize handshake over stdio to confirm it still starts and responds. Fixes modelcontextprotocol#4782
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
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.
Bisected this a bit further than the issue's own finding: it isn't
@vitest/coverage-v8specifically, plainvitestalone triggers the crash, even in an otherwise empty package.json. So it's an npm 10.x arborist bug in peer-dependency resolution, not anything about this repo's dependency graph. Node 24's bundled npm 11.19.0 resolves the exact same package.json with no errors and no extra flags; npm 10.9.8 (what the unpinnednode:22-alpinetag ships today) still crashes.release.ymlalready upgrades past this for a different reason (OIDC trusted publishing needs npm >=11.5.1, and its own comment says node 22's bundled npm is 10.x), so I did the same thing in each builder stage rather than adding a--legacy-peer-depsworkaround or bumping the base image's node major. Confirmed npm 10.9.x in the release stage still reads a lockfile that npm 11 wrote vianpm ci, so nothing downstream needs to change.One thing that surprised me: none of the "Build"/"Test" CI jobs actually build these Dockerfiles. They run
npm cifrom a full monorepo checkout against the checked-in root workspace lockfile, a different install path that never hits this, which is probably why it shipped unnoticed.Ran
docker buildx build --no-cachefor all four servers against a fresh main checkout first and got the issue's exact error on every one, then again on this branch where all four build clean. Also ran each built image through a real MCPinitializehandshake over stdio to confirm it still starts and responds, and drovefilesystemthe same way with a mounted directory.