Test: assert the integrations version export is well-formed semver (stacked on #236) - #479
Open
AmaadMartin wants to merge 1 commit into
Conversation
The consistency assertion pins version.ts to the sibling manifest, but both files are rewritten from a single release-please computed value, so a malformed version propagates to both and passes unnoticed. Assert the shape independently so the exported constant is checked, not just its agreement with package.json. The prerelease branch of the pattern is deliberate: release-please's generic updater writes whatever version it computes, and an -rc bump must not make this test the next stale one.
This was referenced Aug 1, 2026
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.
Please ensure you have read the contribution guide before creating a pull request.
Link to Issue or Description of Change
Link to an existing issue (if applicable):
Not applicable — no public issue tracks this.
Or, if no issue exists, describe the change:
Problem:
integrations/test/version_test.tspinned the exported version to ahardcoded literal (
expect(version).toBe('1.3.0')) whileintegrations/src/version.tshad moved on. That literal is structurallyguaranteed to rot:
release-please-config.jsonregistersintegrationswith anextra-filesentry forsrc/version.tsand groups it underlinked-versions, soevery release rewrites
integrations/src/version.tsandintegrations/package.jsontogether and never touches the test. The failure survived multiple releases because
the
unit:integrationsvitest project was not referenced by any rootnpmscript,so CI never loaded
integrations/test/**.#236 already fixes both of those. It replaces the literal with an assertion
against the sibling manifest and adds
--project unit:integrationstotest,test:unitandtest:coverage. This PR does not re-implement any of that.Solution: this PR adds the one assertion #236 does not have — that the exported
versionis a well-formed semver string — and nothing else.Why it is not redundant with the consistency assertion: both files are rewritten
from a single release-please-computed value, so a malformed version propagates to
version.tsandpackage.jsonidentically and the consistency check stillpasses. The two assertions pin different properties — agreement between the files,
and the shape of the value itself. Mutation A below demonstrates exactly this: with
both files set to
'not-a-version', #236's assertion is green and only the new onefires.
The prerelease branch of the pattern (
(-[\w.]+)?) is deliberate. release-please'sgenericupdater writes whatever version it computes, and a1.6.0-rc.1bump mustnot turn this test into the next stale one (mutation D).
Collision check (performed before writing any code, as required).
gh pr list --repo AmaadMartin/adk-js --state open --limit 1000returned 378 openPRs. #236 (
fix/run-unit-integrations-vitest-project, OPEN, MERGEABLE) touches thesame two files and lands the bulk of this work, so rather than open a competing
implementation this PR is stacked on #236's branch. I verified #236 empirically
rather than trusting its diff: applied its test file to a clean checkout, ran the
targeted project (passing), and confirmed
tsc --noEmitreports no diagnostics forintegrations/test/**— itsimport ... with {type: 'json'}form is valid under therepo's
nodenextconfig, and is in fact more robust than areadFileSync+fileURLToPathform because it involves no path or cwd resolution at all. Adjacentbut non-colliding, checked by filename: #343 and #418 (CI guards under
tests/integration/repo_config/that fail when a vitest project or script isunreferenced — complementary to #236, not duplicative), #297
(
tests/integration/release/version_consistency_test.ts, the repo-levelcross-package check), and #417/#258 (
core/devversion tests). This PR touchesnone of those paths.
On rewriting an existing test. The repo convention is add a new test, do not
rewrite an existing one. This PR adds a second
it()and leaves #236'sassertion untouched. The original
expect(version).toBe('1.3.0')was removed by#236, under the documented exception that the assertion encoded wrong behaviour — it
pinned a value release-please is contractually required to change. No test was
skipped, disabled, weakened, or deleted here.
Testing Plan
Please describe the tests that you ran to verify your changes. This is required for all PRs that are not small documentation or typo fixes.
Unit Tests:
[x] I have added or updated unit tests for my change.
[x] All unit tests pass locally.
Proof each test can fail. Every assertion was run against mutated source and
observed to fail; all mutations were reverted.
version.tsandpackage.jsonboth →'not-a-version'version.ts→'9.9.9'(manifest untouched)1.6.0(simulates the next release bump)1.6.0-rc.1(prerelease bump)Mutation A — the one that proves the new assertion carries signal #236 does not:
Mutation B:
Mutations C and D are the anti-staleness evidence: the pre-fix test failed this
simulation by construction (it asserted a frozen literal), while the post-fix test
survives a normal bump and a prerelease bump with zero edits. Together they also
exercise both branches of the regex's optional prerelease group (absent in C,
present in D).
Manual End-to-End (E2E) Tests:
From the repository root, on this branch:
To observe the original bug, check out
mainand run the same vitest command:AssertionError: expected '1.5.0' to be '1.3.0'atversion_test.ts:12.Known pre-existing condition, not introduced here:
npm run ts:checkexitsnon-zero on this branch. It reports 45 findings, and the set is byte-identical
with and without this commit (captured by stashing the change and diffing the two
outputs) — none of them are in
integrations/test/**. They come from #236's basecommit, which is an older
main. This PR neither adds to nor fixes them.CI note:
.github/workflows/validation.yamltriggers onpull_requestagainstmain. Because this is a stacked PR whose base isfix/run-unit-integrations-vitest-project,those jobs will not run here; the commands above were run locally on the exact pushed
commit instead.
Checklist
[x] I have read the CONTRIBUTING.md document.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] I have added tests that prove my fix is effective or that my feature works.
[x] New and existing unit tests pass locally with my changes.