fix: fall back to package.json for CLI version detection

[AztecBot]

Summary

Fixes aztec --version returning unknown when installed via install.aztec-labs.com.

Closes https://linear.app/aztec-labs/issue/A-642/aztec-version-returns-unkonwn

ClaudeBox log: https://claudebox.work/s/9b17d34db367f45c?run=1

[AztecBot]

✅ Successfully backported to backport-to-v4-staging #21410.

[benesjan]

@ludamad I would ping you about this on slack but at this point I don't know how so asking here.

2 things seem strange to me in this function:

1. We are getting the version here from .release-please-manifest.json which seems strange given that release please is deprecated. Also it doesn't seem to correctly resolve the specific version (e.g. a given nightly) and instead it just resolves the future stable version (e.g. currently 4.3.0 on v4).
2. When we don't find the package.json we don't error out and instead we just return undefined.

Given these 2 problems I implemented my own function in this PR that looks as follows:

/**
 * Returns the package version for embedding in contract artifacts or `dev` if the version in package.json is
 * the placeholder value (that would indicate that this is used from a locally checked out monorepo instead of npm).
 */
function getPackageVersionOrDev(): string {
  const dir = dirname(fileURLToPath(import.meta.url));
  const packageJsonPath = resolve(dir, '../../../package.json');
  const version = JSON.parse(readFileSync(packageJsonPath).toString()).version;
  return version === '0.1.0' ? DEV_VERSION : version;
}

What this does is that it returns the version from package.json or "dev" string when the code is run froms a checked out monorepo and not a real release.

I think we should replace the getPackageVersion function with my implementation.

(and maybe drop the .release-please-manifest.json file)

Would you agree?

[benesjan]

AI feedback

Agree with the diagnosis, broadly agree with the replacement, but a few wrinkles before wholesale replacing it.

On the diagnosis — yes:

• .release-please-manifest.json currently holds 5.0.0 in this checkout. That's the next stable target, not the actually-installed/built version. So for nightlies and stable releases the manifest reading is straight-up wrong; package.json (which release tooling stamps at publish time) is the right source.
• Returning undefined forces every caller into ?? '<fallback>' ('', 'unknown', '0.0.0' — all different, none ideal). A typed string is cleaner.

Wrinkles to think about before swapping:

1. Path depth. Your snippet uses ../../../package.json but the existing fallback in this file uses ../../package.json. For dest/update-checker/package_version.js in the published stdlib package, ../../ is the package root. Make sure the depth in feat: stamping aztec version into contract artifacts #22550 matches the file's actual location, not a copy-paste from elsewhere.

2. Caller behavior change in dev. Today, in a repo checkout, every caller sees 5.0.0. After the change they'll see 'dev'. Mostly fine, but warn_if_aztec_version_mismatch.ts builds expectedTag = \v${version}`→'vdev'and will then warn on every aztec-nr dep. That caller needs an explicitif (version === DEV_VERSION) return;` guard.

3. Other callers of ?? ''. aztec-node/server.ts etc. compare versions across the network — if the node reports 'dev', downstream comparisons should treat that explicitly rather than as "just another version string." Worth a pass.

4. Don't delete .release-please-manifest.json in this PR. Even if release-please is deprecated, that file may still be consumed by current release tooling / GH actions. Confirm it's actually unused first; it's a separate, riskier change from "stop reading it from JS."

5. Naming. getPackageVersionOrDev is fine, but since you're replacing the canonical one, I'd just keep getPackageVersion(): string (always-returns-a-string semantics, with 'dev' baked in) so callers don't need to know the suffix. The behavior is now "the package version, or DEV_VERSION for unstamped checkouts."

So: yes, replace it. But fold the dev guard into the version-mismatch warner in the same PR, double-check the path depth, and split off the manifest-file deletion.

[benesjan]

Decided to go ahead and tackled this in #22941