GeezerVison

Fixes #3779

ng add @angular/fire@canary now installs the newest canary build instead of the release candidate, and keeps doing so after 21.0.0 ships.

Changes

• tools/canary-version.js picks the version a canary is named after: one patch above the highest published version of the same major that is not a canary, or package.json's version without its prerelease part if that is higher.
  • Today that gives 21.0.1-canary.<UTC commit time>.sha-<short sha>.
  • After 21.0.0 ships it gives 21.0.1-canary.*, and after 21.0.1 ships, 21.0.2-canary.*.
  • With package.json at 22.0.0-rc.0 and nothing in 22 published yet, it gives 22.0.0-canary.*.
• tools/build.sh reads the published versions with npm view @angular/fire versions --json and stops the build if npm can't be read. Tagged releases are named exactly as before.
• tools/canary-version.jasmine.ts covers the cases above, and tsconfig.jasmine.json now includes tools/**/*.jasmine.ts so test:node runs it.
• The warning about a prerelease in package.json is removed, since a prerelease there no longer changes the name.

Behavior to know

• Someone on a 21.0.1-canary build isn't offered 21.0.0 by ng update once it ships, because 21.0.0 ranks below what they have. To go back to a release they install it directly, for example npm install @angular/fire@21.
• A canary built while a release is publishing can be named at that release's version and rank below it until the next canary build.
• Anyone with ^<canary> saved, which npm install @angular/fire@canary writes, moves to the next patch release when it ships and stays there, because a prerelease only matches a range on its own patch number. ng add @angular/fire@canary saves the exact canary version instead, so those installs never move on their own.

Verification

• npm run test:node: 342 specs, 0 failures. Counting published canaries again fails 1 spec, and using semver.inc on the release candidate (which turns 21.0.0-rc.1 into 21.0.0) fails 5.
• Ran tools/build.sh in a scratch repository with npm view answering from version lists and the build step stubbed:
  • Today's npm versions give 21.0.1-canary.*.
  • Adding 21.0.0 gives 21.0.1-canary.*, adding 21.0.1 gives 21.0.2-canary.*.
  • Adding 21.1.0-rc.0 gives 21.1.1-canary.*, adding 21.0.1-rc.0 gives 21.0.2-canary.*.
  • Adding earlier 21.0.1-canary.* builds still gives 21.0.1-canary.*.
  • Adding 20.0.4 or 22.0.0-rc.0 doesn't change the 21 canary.
  • With npm unreachable the build stops with an error.
• With npm's version picker (npm 10.9.8) in each of those states, ^<canary> selects the canary, and ^21.0.0, ~21.0.0, ^21.0.0-rc.1 and ^20.0.0 never select a canary.