Versioning & support

# What a release actually runs. --bump is the workflow's one input,
# and this is the step that refuses it.
pnpm release:prepare --bump=minor

# Illustrative output, with one breaking commit on the branch:
#
#   Refusing --bump=minor: 1 breaking commit(s) since v14.0.0.
#     feat(select)!: clearable is opt-in
#   A `!` type or a `BREAKING CHANGE:` footer requires --bump=major.
#
# Exit status 1. No version written, no changelog, no release PR.

It exists because the opposite shipped. v12.2.0 was a minor that carried a BREAKING CHANGES heading in its own changelog — select: clearable is opt-in — and an app on ^12.1.0 received it on the next install with nothing said. The bump was a value someone picked from a dropdown, and nothing connected it to the commits it was about to publish. That connection is now a step in the release, which is the only place it can live: a review can miss it, a convention can be forgotten, and a changelog that contradicts its own version number is written after the decision has already been made.

Two smaller rules complete it. rc is exempt, and has to be: a release candidate is where a major is staged, and it publishes to the next dist-tag rather than to latest, so nobody receives it by upgrading. And “a patch is only fixes” is a convention, not a gate — 10.2.1 shipped a Features section. Nothing in that patch broke anything, which is why the guard is aimed where it is; but if you want to know exactly what a version contained, the changelog for it is generated from the commits rather than written, so it tells you.

The last row is the honest one and it is worth stating plainly rather than leaving to a reader with a .d.ts open: being exported is not the same as being supported. An entry point's public-api.ts exports a few helpers that exist because a component needed them, and a symbol like that carries no promise until something describes what it promises. The machine-readable half of this is the @internal marker, which survives into the published types — so the question “may I use this?” has a grep-able answer for one category and, for now, a judgement call for the other.

# Everything on this page is a fact about the repository. Read it there.
cat node_modules/ngwr/package.json | jq .peerDependencies   # the ranges
grep -rn "@internal" node_modules/ngwr/types                # what is not API
npm view ngwr time                                          # every release, dated
npm view ngwr dist-tags                                     # latest, and any rc on `next`

Reporting is private: GitHub's private vulnerability reporting or email, never a public issue. The targets — 72 hours to acknowledge, 7 days to triage, 30 days to a fix or workaround for high and critical — are in SECURITY.md, with the scope: the published package and its bundled assets, not this site and not the dependencies, which go upstream.

Below the floor, the install succeeds and the build is what fails. npm, pnpm and yarn all treat an unsatisfied peer as a warning, so adding ngwr to an Angular 21 project prints “Issues with peer dependencies found” and exits 0. The failure surfaces later, in the linker, as Unsupported enum value for [object Object] pointing into a fesm2022 bundle — a message that never mentions a version. Read the peer warning at install time; it is the only place the real reason is printed.

Above the ceiling, nobody knows yet, and the honest answer is a procedure rather than a range. When a new Angular major lands, ngwr has not been built or tested against it — the gates run on the Angular the repository is pinned to. So: upgrade Angular on a branch, run your own suite, and expect a supporting ngwr release rather than a widened range, because the fix for a framework break is code. Nothing about the open range makes an untested combination work, and nothing about it will warn you that you are in one. The gates page lists what runs and what each gate cannot see; there is one maintainer and no dated commitment, which is worth weighing before you plan an upgrade around a release that has not been announced.

TypeScript and Node are decided by your Angular, not by ngwr. The package declares no engines field and no TypeScript peer at all: it ships pre-compiled bundles and .d.ts files, so the compiler version that matters is the one Angular's own peer range names — typescript >=6.0 <6.1 for Angular 22 — and the Node version is whatever your Angular CLI accepts. That is a deliberate absence rather than a missing field: a second range here could only ever contradict the first one.

Three things follow, and they are what a team can actually act on. One: a caret range on a major is a safe range now, which it demonstrably was not on v12 — that is what the guard at the top of this page buys, and it is the whole reason it is worth stating publicly instead of leaving you to infer a policy from a changelog. Two: budget for reading a migration on each major, not for a rewrite — the migration guide covers every break back to v6, and ng update ngwr@14 rewrites the half a codemod can honestly repair and reports the half it cannot. Three: check rather than trust this paragraph, because a page written today describes the releases that existed today.

# Pin the major and let the minors in. That is a safe range now — the guard
# above is what makes it one — and it was not on v12, where 12.2.0 was a minor
# carrying a breaking change.
npm pkg set dependencies.ngwr="^14.0.0"

# Then read what a range would actually have picked up, before you widen it.
npm view ngwr versions --json

What none of this buys: there is no commercial support, no SLA and no contract — Quality says so in the same words. The library is MIT and every gate runs in the public repository, so a fork is a real option; that is the fallback the licence gives you, not a plan anyone is offering to run for you.