fix(libs): align the generated version constants with the manifests - #1111
Merged
Merged
Conversation
The four committed package-version.ts files read 0.0.66 while their package.json files read 0.2.0. The constant feeds runtime telemetry, so a source checkout reported a version three releases old. They drift because the release flow never commits them: nx release version runs its prebuild BEFORE rewriting the manifests, so a regeneration during a release embeds the previous version. Published artifacts are unaffected, since the tag-driven publish rebuilds from the versioned sources. Regenerated from the current manifests with the same assemble-package target that produces them. A side effect worth having: a library test run no longer leaves these four files dirty, which had been mistaken for spurious churn and reverted by hand. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
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.
The four committed
package-version.tsfiles read0.0.66while theirpackage.jsonfiles read0.2.0. That constant feeds runtime telemetry, so a source checkout reported a version three releases old.Why they drift
The release flow never commits them, and cannot easily.
nx release versionruns its prebuild before rewriting the manifests, so a regeneration during a release embeds the previous version.docs/RELEASE.mdwarns about exactly this. Published artifacts were never affected, because the tag-driven publish rebuilds from the versioned sources; only the checked-in copies went stale.What this does
Regenerates all four from the current manifests using the same
assemble-packagetarget that produces them. No hand-editing. The tracked.install-collectoroutputs regenerated byte-identical, so nothing else moved.A side effect worth having: a library test run no longer leaves these four files dirty. That churn had been mistaken for a spurious
0.1.0bump and reverted by hand repeatedly, including by me earlier today. With the committed values correct, the regeneration is a no-op.Verification
nx run-many -t test,buildacross chat, ag-ui, langgraph and render passes, and the working tree after that run contains only the four intended files.Follow-up not done here
Nothing prevents this drifting again. The obvious guard, a unit test comparing the constant to
package.json, would be vacuous: the build regenerates the file and runs before the test, so it would always compare a freshly written value against its own source and pass. A real guard has to check the committed file, for example a CI step running the prepare-install target and thengit diff --exit-code. That is a workflow change and deliberately out of scope here rather than shipped as a test that looks like protection and is not.🤖 Generated with Claude Code