fix: dynamically increment prerelease versions in publish.sh

[inlined]

Description

Fixes an issue in scripts/publish.sh where prerelease publishing (e.g. running with --prerelease) would fail if rc.0 was already published on npm for that target version series, since it always bumped from the stable version. It now dynamically checks npm for any existing prerelease versions of the target version series, and performs a prerelease increment (e.g., to rc.1) if one exists.

Newly assumes the jq command exists to avoid silly node scripts (will need to test in prod or build a new container). Now handles gh not existing since it didn't in the past.

Release Notes

relnote: chore: improve release script

[gemini-code-assist]

Code Review

This pull request updates the prerelease versioning logic in scripts/publish.sh to check npm for existing prerelease versions in the target range and increment them if found, rather than always starting from the stable version. The reviewer noted that parsing the raw output of npm view with tail and grep is fragile and prone to errors due to output formatting variations, sorting assumptions, and a hardcoded regex. They suggested a more robust approach using Node.js and the semver package to parse the JSON output safely.

[ajperel]

I was doing some diving to fully understand this. It totally works and I'm fine merging it. Gemini thinks if we're already using jq it'd be slightly more robust to use it:

LATEST_VERSION=$(npm view "$PACKAGE_NAME" versions --json | jq -r '[.[] | select(test("^[0-9]+\\.[0-9]+\\.[0-9]+(-rc\\.[0-9]+)?$"))] | .[-1]')

It does all the stripping so you just reduce to testing the version numbers to be fair... but I kinda doubt npm view versions --json is going to change much.

[ajperel]

Why is it safe to assuming jq will be installed? It wasn't on my cloudtop for example (though I've now installed it).