angular/angular

How to contribute

This section documents the day-to-day mechanics of contributing to Angular itself: the PR process, branch and version management, testing patterns, debugging, and the conventions enforced by review and CI. For contribution policy (CLA, issue triage, what gets accepted), the source of truth is CONTRIBUTING.md at the repository root.

The minimum bar for a PR

The team's published expectation:

The PR is tied to a tracked issue or describes the design clearly. Speculative implementation against an unaccepted feature request risks being closed.
The change improves code quality (e.g., resolves a TODO) or impacts a feature.
Tests cover the behavior — see testing. Performance optimizations need a benchmark.
The commit message follows the conventional commit format below — release notes are generated from the messages.
Lint and format both pass: pnpm lint is required.
The Contributor License Agreement (CLA) is signed under the same email as the commits.

The branches

Released majors live on patch branches; the next major lives on main:

main — the next major (v22 at this writing).
<major>.<minor>.x — release branches for shipped majors. Patches and security backports are cherry-picked here.
LTS windows: each major gets ~12 months of LTS after a 6-month active period. Currently v21 (LTS), v20 (LTS), v19 (maintenance).

The full policy is in contributing-docs/branches-and-versioning.md.

Commit messages

Angular's conventional commit format is enforced by ng-dev and PR review:

<type>(<scope>): <short summary>

<body>

<footer>

<type> is one of build, ci, docs, feat, fix, perf, refactor, test. <scope> matches a package name (core, compiler-cli, router, forms, ...) or one of the special scopes dev-infra, docs-infra, migrations, devtools, vscode-extension. The summary is imperative present tense, lowercase, no trailing period.

Breaking changes are signaled in the footer with BREAKING CHANGE: ... and trigger major-version handling. Deprecations use DEPRECATED: ....

The full spec lives in contributing-docs/commit-message-guidelines.md.

The PR lifecycle

graph LR
  Issue[Filed issue] --> Discuss[Design discussion in issue]
  Discuss --> Branch[Fork + branch from main]
  Branch --> Code[Code + tests]
  Code --> Lint[pnpm lint, public-api:check]
  Lint --> Open[Open PR against main]
  Open --> Review[Caretaker / CODEOWNER review]
  Review --> Fixup[Fixup commits via --fixup]
  Fixup --> Merge[Squash merge by angular-robot]
  Merge --> Cherry["Cherry-pick to release branches<br/>(if labeled)"]

Reviewers expect:

Rebased branches; merge commits in PRs are rejected.
Fixup commits via git commit --fixup HEAD (auto-squashed on merge). The using-fixup-commits.md doc has a walkthrough.
A Closes #N or Fixes #N footer when applicable.
All goldens/public-api/*.d.ts updates checked in.

What ships where

@angular/* packages publish to npm via the release pipeline driven by ng-dev. Every release also publishes a snapshot to the <package>-builds GitHub repos for downstream pre-release testing (e.g., angular/core-builds).

Documentation changes to adev/src/content/ deploy to angular.dev via the Firebase pipeline (the adev-preview-build.yml and adev-preview-deploy.yml workflows).

DevTools releases are managed by devtools/tools/release.mts; Chrome and Firefox builds are produced separately.

Sub-pages

development-workflow — the branch / commit / fixup / squash lifecycle in detail.
testing — how Bazel runs tests, the zoneless "Act, Wait, Assert" pattern, browser vs node tests, integration tests.
debugging — ng.profiler, focus tests with fit(), logs, source maps, common stuck points.
patterns-and-conventions — naming, error handling, getters/setters, RxJS aliasing, JSDoc rules.
tooling — ng-dev, bazelisk, ibazel, tsec, the goldens/ snapshots, the migrations system.

Built by Factory AutoWiki from public repository content. It is a generated preview for codebase exploration, not source-maintained documentation.