Stop routine updates from starving the engine bump - #28
Merged
Conversation
Dependabot has no priority setting, and a full queue means it opens no more PRs at all. This repo is the proof: it pins ^0.5.1 while the engine is at 0.5.2 and no bump PR was ever raised, because the npm queue is full at five routine updates (one permanently red on zod 4). Every dependency except the engine now rides in one grouped PR, so routine updates take a single slot however many are pending, while @infino-ai/infino matches no group and always gets its own. zod's major is ignored until its z.record migration lands, so a known-incompatible major cannot sit red inside the group and block everything with it.
The MCP tool schema called z.record(valueSchema), the zod 3 form that assumes string keys; zod 4 requires the key schema explicitly, which is why its major sat red and held a queue slot. The two-argument form is valid in both zod 3 and 4, so this migrates the call site without moving the dependency, and dependabot's zod 4 PR now passes on its own instead of needing an ignore entry. Verified both ways: all 103 tests pass on the pinned zod 3, and again with zod 4 installed locally. The MCP SDK already accepts '^3.25 || ^4.0', so nothing else stood in the way.
Dependabot's default only edits package.json when the new version falls outside the declared range, so the engine moving inside ^0.5.x would update the lockfile alone, leaving the tested floor and the published floor apart: CI verifies the new version while the package still accepts any 0.5.x, including patches nothing verifies any more. versioning-strategy: increase moves the floor to the version tested. The setting is per-ecosystem, so routine dev-dependency bumps will also touch package.json and land in the minor bucket.
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.
Dependabot has no priority setting, and a full queue means it simply opens no more PRs, so the dependency that matters most can be the one left out. That is not hypothetical here: this repo pins
^0.5.1while the engine is at 0.5.2, and no bump PR exists, because the npm queue is full at 5 (one of them permanently red).Two entries for the same ecosystem and directory are not allowed, so the engine cannot have its own limit. What works instead: every dependency except the engine rides in one grouped PR, occupying a single slot however many are pending, while the engine matches no group and therefore always gets its own PR (GitHub: "any outdated dependencies that do not match a rule are updated in individual pull requests"). The queue can no longer fill, so the engine can no longer be squeezed out.
Also ignoring
zod4 until thez.record(key, value)migration lands (PR #19 is red on exactly that), so a known-incompatible major cannot sit inside the grouped PR and block every routine update with it. Drop the ignore with the migration.