René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"ng add @angular/fire@next records a caret range that silently drifts to canary builds","articleBody":"### Version info\n\n**Angular:** 21.2.x\n\n**Firebase:** 12.x\n\n**AngularFire:** 21.0.0-rc.0 (`@next`)\n\n### How to reproduce these conditions\n\n1. `ng add @angular/fire@next` — package.json records `\"@angular/fire\": \"^21.0.0-rc.0\"` (npm's default caret).\n2. Any later fresh install (new clone without a reused lockfile, `npm update`, CI without a lockfile) resolves that range again.\n\n### Expected behavior\n\nInstalling a specific prerelease keeps that prerelease until the developer deliberately upgrades.\n\n### Actual behavior\n\nThe caret range also matches the `21.0.0-rc.0-canary.\u003csha\u003e` builds auto-published for every merge to main, which sort higher than `rc.0` — so the resolved version silently becomes an unreviewed canary snapshot. Nothing in the project changed, but the installed code did, and the resulting breakage doesn't look like a version problem. (Stable ranges like `^21.0.0` don't have this failure — they only drift to reviewed releases.)\n\nProposal: after install, the ng-add schematic pins the `@angular/fire` entry to the exact installed version when the recorded spec is a caret/tilde range around a prerelease. Stable ranges and hand-written range expressions stay untouched.\n","author":{"url":"https://github.com/armando-navarro","@type":"Person","name":"armando-navarro"},"datePublished":"2026-07-09T04:19:53.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/3708/angularfire/issues/3708"}