Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Canary builds are named after the release candidate, so npm ranks them above it

Open Beginner friendly
#3,766 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
74/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
shell

Research direction

Start with the root package.json and tools/build.sh, then trace how versions are selected for canary and tagged release builds. Confirm the resulting package versions against npm semver ordering, with canaries ranking below the release candidate while tagged releases retain their tag versions.

Written by the indexing model from the issue text.

Description

comp: build/pipeline type: bug version: current (v17+)

ng add @angular/fire@next and ng update @angular/fire@next install a canary, not the release candidate.

When #3674 was merged, 21.0.0-rc.0 was put in package.json, breaking with this repo's previous patterns. #3751 continued this break with 21.0.0-rc.1.

#3709 mitigated the symptom for ng add by writing the exact installed version into the user's package.json. But going back to the old pattern would simplify things further.

Details
  • The root package.json version field holds 21.0.0-rc.1, and tools/build.sh specifies each canary by appending -canary.<short sha> to that field.
    • Every merge to main therefore publishes 21.0.0-rc.1-canary.<sha>, which semver ranks above 21.0.0-rc.1, because the middle identifier parses as the text 1-canary and text outranks a number.
  • ng add @angular/fire@next installs a canary, not the release candidate. The Angular CLI resolves the tag, then writes the range ^21.0.0-rc.1, and npm resolves that to 21.0.0-rc.1-canary.95b3de1.
  • ng update @angular/fire@next does the same, and unlike ng add it leaves a range in package.json rather than an exact version, so the app can drift again on any later install.
  • The version field is not what a tagged release publishes. tools/build.sh takes a tagged release's version from the tag name.
    • At the 19.0.0-rc.5 tag the version field in package.json read 19.0.0, yet the release published to npm from that tag is 19.0.0-rc.5.
    • At the 20.0.1 tag the field read 20.0.0 and the release published to npm is 20.0.1.
  • Releases through v20 named canaries after the release itself, for example 19.0.0-canary.<sha>, which ranks below every 19.0.0-rc.N.
    • The release-candidate string first entered the version field in the v21 preparation commit (#3674).
Scope

Build and packaging. It does not remove the 25 canary builds already published on the 21 line, which keep outranking 21.0.0-rc.1 until 21.0.0 ships.

Dominant language
TypeScript
Stars
7.8k
Forks
2.2k
Avg merge
3d 6h
Merged PRs (30d)
5

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from angular/angularfire

All issues in angular/angularfire

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.