Angular Material and the CDK: what the angular/components repository actually ships

Five packages in one repository, and the different jobs they do

The README lists five published npm packages, and they are not variations on one thing. @angular/material is the Material Design component set: buttons, form fields, dialogs, the pieces you drop into an application. @angular/cdk is the layer underneath, described in the README as a library that helps you author custom UI components with common interaction patterns. @angular/aria is the newest of the three core packages, a collection of headless, accessible directives that implement common WAI-ARIA patterns. The remaining two are wrappers: @angular/google-maps sits on top of the Google Maps JavaScript API, and @angular/youtube-player on top of the YouTube Player API.

The split matters when you pick a dependency. If your team has its own visual language and only needs correct keyboard handling, focus management and overlay positioning, the CDK is the package to install, not Material. Material pulls in the visual layer and the Material Design specification along with it. The aria package goes further in the other direction: directives with no styling at all, following WAI-ARIA patterns, which is what you want when you are building an accessible widget from scratch and do not want someone else's CSS in the way.

The README states two goals for the team: build high-quality UI components developers can drop into existing applications, and provide tools that help developers build their own custom components with common interaction patterns. Those two goals map onto Material and the CDK respectively. The repository is TypeScript, licensed MIT, and the team is part of the Angular team at Google, including both Google employees and community contributors.

How the packages are built and released

The repository is a monorepo built with Bazel. The top level contains BUILD.bazel, MODULE.bazel, MODULE.bazel.lock, REPO.bazel and packages.bzl, and the source for every published package lives under src/. The package.json at the root is named components-srcs and is not itself published; it is the workspace manifest.

Dependency installation goes through pnpm, and the root package.json is explicit about it. Its engines field contains the strings "Please use pnpm instead of NPM to install dependencies" and "Please use pnpm instead of Yarn to install dependencies", and the packageManager field pins [email protected]. If you are used to cloning an Angular repository and running npm install, this one will steer you elsewhere. The repository also carries a pnpm-workspace.yaml and a pnpm-lock.yaml at the top level.

Releases are cut from the same branch structure as the Angular framework. The recent tags show three parallel lines: v22.1.7 as a stable patch, v22.2.0-rc.0 as a release candidate, and v22.2.0-next.5 as a next-channel prerelease. That is the standard Angular cadence, and the README points at the Angular support policy and schedule for the details rather than restating them. The practical consequence for a consumer is that @angular/material and @angular/cdk version numbers track Angular framework versions, so an upgrade of one usually forces an upgrade of the other.

Installing Angular Material and using your first component

The README does not contain install commands. It directs readers to the Getting Started Guide at material.angular.dev/guide/getting-started, and that is where the actual steps live. What the repository does give you is the package names, and they are unambiguous: @angular/cdk, @angular/material, @angular/aria, @angular/google-maps and @angular/youtube-player.

Because the guide is the authority on setup and this article is not, treat the commands below as the shape of the process rather than a substitute for it. A schematic install of the CDK alone, for a project that wants interaction primitives without Material styling, looks like this:

npm install @angular/cdk

The same pattern applies to the other packages, for example npm install @angular/material. After installing, the guide is where you go for the Angular CLI schematics that wire up themes and typography, and for the module imports each component needs. The README's own quick links point at the documentation, demos and guides site as the single entry point.

If you are evaluating rather than installing, the StackBlitz template linked from the README is the fastest way to see the components running without touching your own project. The repository also ships a dev-app and a docs-app, run through Bazel as ibazel run //src/dev-app:devserver and ibazel run //docs:serve, but those are for working on the library itself, not for consuming it. Contributing to the repository is a different exercise from using it: the root package.json routes tests through a script that shells out to Bazel, and the dev environment is documented separately in DEV_ENVIRONMENT.md.

Accessibility and browser support are stated as commitments, with a boundary

The README makes accessibility a defining property rather than a feature. Its definition of high-quality components begins with "Internationalized and accessible so that all users can use them", and the aria package exists specifically to expose WAI-ARIA patterns as directives.

The support matrix is unusually concrete, and it is also narrow in a way worth reading carefully. The team supports the most recent two versions of Chrome including Android, Firefox, Safari including iOS, and Edge. On screen readers, the README names NVDA and JAWS with Firefox or Chrome on Windows, VoiceOver with Safari or Chrome on macOS, VoiceOver with Safari on iOS, Android Accessibility Suite with Chrome on Android, and ChromeVox with Chrome on Chrome OS.

That list is a boundary, not a slogan. If your users are on an older browser, or on a screen reader combination that is not named, you are outside what the team states it supports. The README does not offer a fallback position for those cases. For an enterprise application with a fixed browser baseline that lags by more than two major versions, this is the first thing to check before adopting, and the answer may be that the library is the wrong tool for that deployment.

Where the documentation leaves you on your own

The README is a signpost, not a manual. It contains no API reference, no migration instructions, and no rollback guidance. Everything substantive is delegated: the Getting Started Guide, the CDK category docs, the aria overview, and per-package READMEs for google-maps and youtube-player that live under src/ rather than at the repository root.

Two gaps stand out for anyone planning an upgrade. First, the README states that Angular Material and the CDK follow the same support and release policy as the Angular framework and links to angular.dev/reference/releases, but it does not summarize which versions are currently supported. You have to follow the link. Second, the repository does not document rollback. If a Material upgrade breaks your templates, the README is silent on how to reverse it; version pinning and the Angular update guide are the mechanisms you would have to work out yourself.

There is also a structural cost that the README implies but does not spell out. The repository is Bazel-based and pnpm-only for its own development, which is a heavier toolchain than most consumers need. That is fine, because consumers install published npm packages and never touch Bazel. But it does mean that if you want to patch a bug locally and run the test suite, you are signing up for the full dev environment described in DEV_ENVIRONMENT.md, not a quick npm test.

How the CDK differs from component libraries like PrimeNG or ng-bootstrap

The obvious alternatives for an Angular team are full component libraries such as PrimeNG or ng-bootstrap, and the difference is architectural rather than cosmetic. Those libraries ship finished, styled components: you import a component, you get its markup and its appearance, and customization happens through their theming APIs.

The CDK takes the opposite position. It provides the behaviour, not the look. Overlay positioning, focus trapping, drag and drop, virtual scrolling and similar primitives are exposed as directives and services that you compose into your own components. The README's phrasing is precise about this: the CDK helps you author custom UI components with common interaction patterns. Nothing in it claims to give you a finished widget.

That makes the CDK a poor fit if you want to ship a screen this week and have no design system of your own. It makes it a good fit if you already have one and are tired of rebuilding focus management. @angular/material sits between the two positions: finished components, but the README states customization is bounded by the Material Design specification, so a design language that departs from Material will fight the library. The choice is really about how much of your own design you intend to keep.

Maintenance, licensing and the cost of staying current

The repository is not archived, and its last push was on 2026-09-19. The recent tags show three active release lines, including a stable patch on 2026-09-16 and a release candidate on the same day. The project is maintained by the Angular team at Google alongside community contributors, and it follows the Angular framework's release and support policy rather than setting its own.

The practical upgrade cost follows from that alignment. Because the packages version in step with Angular, a framework major upgrade implies a Material and CDK upgrade in the same window, and the support policy determines how long your current version keeps receiving fixes. The README points to the Angular support policy and schedule for the specifics, and it does not duplicate them.

On licensing, the repository's LICENSE file and the root package.json both state MIT. That is a permissive licence, and it is the same for the published packages. This is a factual note about what the repository declares, not legal advice; if your organization has licence review requirements, the MIT identifier in package.json and LICENSE is the artifact to hand to that process. The README also links a SECURITY.md at the repository root, which is where security reporting goes rather than the issue tracker.

Editorial conclusion

Adopt @angular/material or @angular/cdk if you are already on a supported Angular version and want components the Angular team maintains under the same release policy as the framework. Do not adopt it if you need a design system outside the Material Design specification, since the README states customization is bounded by that spec. Before committing, open material.angular.dev/guide/getting-started and check your Angular version against the Angular support policy and schedule, because the repository defers version compatibility entirely to that document.

Frequently asked questions

Official sources

1. angular/components on GitHub
2. License: MIT
3. Project website
4. README
5. Releases