refactor: getPackageVersion fn cleanup#22941
Merged
benesjan merged 1 commit intoMay 5, 2026
Merged
Conversation
…lease manifest
The release-please manifest holds the *next* stable target rather than the
actually-installed/built version, so reads were stale for nightly and stable
releases. Read from the stdlib `package.json` (which release tooling stamps at
publish time) and substitute `DEV_VERSION` ('dev') for the `0.1.0` placeholder
used in monorepo checkouts.
Also narrows the return type from `string | undefined` to `string` and drops
the now-dead `?? '<fallback>'` chains in callers. `warnIfAztecVersionMismatch`
gets an early return on `DEV_VERSION` so monorepo checkouts no longer warn on
every aztec-nr dep.
benesjan
changed the title
benesjan
changed the title
getPackageVersion fn cleanup
alexghr
reviewed
May 5, 2026
Contributor
alexghr
left a comment
alexghr
left a comment
There was a problem hiding this comment.
Is it because we don't publish .release-please-manifest.json to npm? But in that case I would have expected the fallback to kick in.
Collaborator
|
we're ok with this reporting 0.0.1 in dev copy? |
Contributor
Author
@alexghr TBH I don't know but anyway it's unnecessary there as the version gets stamped to package.json of the stdlib package.
@ludamad it's the other way round - if there is 0.0.1 then it means the version didn't get stamped in package.json which implies a local repo checkout. I want this to return dev since I need to stamp something into contract artifact in that other PR of mine and dev seems nicer than 0.0.1. |
ludamad
approved these changes
May 5, 2026
AztecBot
pushed a commit
that referenced
this pull request
May 5, 2026
[This other PR](#22941) of mine was motivation for this because there we need to stamp aztec version into contract artifact and the current `getPackageVersion` was not helpful in that because it failed to resolve the actual version (e.g. `v4.3.0-nightly.20260427` instead of `v4.3.0`). To workaround this I will no longer read the version from `.release-please-manifest.json` and will read it from package.json instead where the version is stamped during a release. If the code is not run from a release the version is simply populated with "dev" which seems better then returning undefined and forcing the callsites to deal with it. Bothering Adam and Alex with a review here since you are the only people that seemed to have touched the function. ## AI Summary - `getPackageVersion` previously read from `.release-please-manifest.json`, which holds the *next* stable target (currently `5.0.0`) — not the actually-installed/built version. So nightlies and stable releases reported a stale version. - It now reads from the stdlib `package.json` (which release tooling stamps at publish time) and substitutes `DEV_VERSION` (`'dev'`) for the `0.1.0` placeholder used in a monorepo checkout. - Return type narrowed from `string | undefined` to `string`, and the now-dead `?? '<fallback>'` chains in callers (`aztec-node`, `aztec` CLI, `cli-wallet`, `txe`) are dropped. - `warnIfAztecVersionMismatch` gets an early return on `DEV_VERSION` so monorepo checkouts no longer spam warnings about every aztec-nr dep tag mismatch (previously it would compare against `v5.0.0`, now it would have compared against `vdev` — both wrong). `.release-please-manifest.json` is left in place for now since release tooling may still consume it; removing it can be a separate change. Context from #21382 review thread: https://github.com/AztecProtocol/aztec-packages/pull/21382/files#r3182335186
Collaborator
|
✅ Successfully backported to backport-to-v4-next-staging #22924. |
This was referenced May 5, 2026
AztecBot
added a commit
that referenced
this pull request
May 5, 2026
BEGIN_COMMIT_OVERRIDE docs: add map and state variable docs (#22824) fix: e2e compat should not fail for contracts added after legacy stables (#22900) chore: fix kv-store browser tests hangs (#22721) feat: kv-store sqlite backend with page level encryption (#22759) fix: install node 22 for aztec-cli acceptance test (#22917) feat: backport kv-store sqlite encryption (#22759) to v4-next (#22927) fix(docs): correct llms.txt links for versioned developer docs (#22819) feat(docs): improve discoverability of Aztec.nr API reference docs (#22861) feat(docs): backport improve discoverability of Aztec.nr API reference docs (#22861) to v4-next (#22931) feat(aztec-nr): add call_self stubs for utility functions (#22885) docs: add map and state variable docs (backport #22824) (#22880) refactor: `getPackageVersion` fn cleanup (#22941) fix(ci): skip acceptance test for canary -commit. tags (#22951) fix: closing db, correct stub side effects (#22939) END_COMMIT_OVERRIDE
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
4 participants
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.
This other PR of mine was motivation for this because there we need to stamp aztec version into contract artifact and the current
getPackageVersionwas not helpful in that because it failed to resolve the actual version (e.g.v4.3.0-nightly.20260427instead ofv4.3.0). To workaround this I will no longer read the version from.release-please-manifest.jsonand will read it from package.json instead where the version is stamped during a release. If the code is not run from a release the version is simply populated with "dev" which seems better then returning undefined and forcing the callsites to deal with it.Bothering Adam and Alex with a review here since you are the only people that seemed to have touched the function.
AI Summary
getPackageVersionpreviously read from.release-please-manifest.json, which holds the next stable target (currently5.0.0) — not the actually-installed/built version. So nightlies and stable releases reported a stale version.package.json(which release tooling stamps at publish time) and substitutesDEV_VERSION('dev') for the0.1.0placeholder used in a monorepo checkout.string | undefinedtostring, and the now-dead?? '<fallback>'chains in callers (aztec-node,aztecCLI,cli-wallet,txe) are dropped.warnIfAztecVersionMismatchgets an early return onDEV_VERSIONso monorepo checkouts no longer spam warnings about every aztec-nr dep tag mismatch (previously it would compare againstv5.0.0, now it would have compared againstvdev— both wrong)..release-please-manifest.jsonis left in place for now since release tooling may still consume it; removing it can be a separate change.Context from #21382 review thread: https://github.com/AztecProtocol/aztec-packages/pull/21382/files#r3182335186