Angular CDK: What Ships in @angular/cdk and Keeping It Current

The angular cdk npm package (@angular/cdk) is the Component Dev Kit that Angular Material is built on: a set of unstyled behavior primitives — overlays, accessibility helpers, drag-and-drop, virtual scrolling, layout observers — that you can use directly in your own components. It is developed in the same repository as Angular Material (angular/components), releases in lockstep with Angular's major versions, and is one of the dependencies most likely to silently fall behind because "it just works." This guide walks through what actually ships in the package, how its version policy binds you to the framework's upgrade cadence, and a maintenance routine that keeps it current without drama.

What is actually in the box

Install is a one-liner, and the package is tree-shakable by entry point:

npm install @angular/cdk

Each capability lives in a secondary entry point, so importing @angular/cdk/overlay pulls nothing from @angular/cdk/drag-drop. The modules you will reach for most:

• a11y — focus traps, FocusMonitor, LiveAnnouncer for screen-reader announcements, and high-contrast detection. If you build any custom interactive component, this module is the difference between accessible and not.
• overlay — the positioning engine behind Material's dialogs, menus, and tooltips. Handles flexible connected positioning, scroll strategies, and backdrop management.
• drag-drop — cdkDrag/cdkDropList directives with sorting, list-to-list transfer, and custom previews.
• scrolling — cdk-virtual-scroll-viewport for rendering only visible rows in large lists.
• layout — BreakpointObserver for media-query-driven behavior in TypeScript rather than CSS.
• table — the headless cdk-table that Material's mat-table wraps.
• portal, dialog, listbox, menu, stepper, tree, clipboard, text-field — smaller primitives following the same pattern: behavior and accessibility, zero visual opinion.

The design intent, stated since the CDK's introduction by the Angular Material team, is that these are the pieces "with the styles stripped out": you get interaction logic and a11y correctness, and bring your own design system. Teams that build internal component libraries on the CDK rather than from scratch inherit years of edge-case fixes — focus restoration after dialog close, RTL positioning, iOS scroll quirks — for free.

Versioning: the CDK moves when Angular moves

@angular/cdk majors track Angular majors. CDK 19 pairs with Angular 19, CDK 20 with Angular 20 (current as of mid-2025), and each major declares a peer dependency range on @angular/core and @angular/common. Three practical consequences:

1. You cannot pin the CDK and freeze it. Angular's support policy gives each major roughly 18 months (active support, then long-term support). When your Angular version leaves LTS, so does your CDK, and security fixes stop landing for both.
2. Minor and patch releases are frequent and low-risk. The angular/components repo publishes patches on a weekly-ish rhythm. These are the updates to automate.
3. Version skew is a real failure mode. @angular/cdk at 19.x with @angular/material at 20.x produces runtime errors and subtle styling breakage. The two packages must always share a major and should share the exact version.

Check for skew in one command:

npm ls @angular/cdk @angular/material @angular/core

If a third-party library (a date picker, a grid) pins an old CDK, npm may hoist duplicates. Two CDK copies means two overlay containers and focus management fighting itself — worth an explicit overrides entry in package.json or a conversation with the library maintainer.

Keeping it current without drama

The reliable pattern is to let the Angular CLI drive, because CDK schematics run migrations for renamed APIs:

ng update @angular/core @angular/cli
ng update @angular/cdk @angular/material

ng update respects peer dependency constraints and applies automated code migrations, which plain npm update does not. A sane cadence:

• Patch/minor updates: automated weekly via Renovate or Dependabot, grouped into a single "Angular packages" PR so the framework, CDK, and Material move together. Grouping matters — individual bumps are how skew sneaks in.
• Major updates: scheduled within a quarter of each Angular major, while the previous major is still in support. Waiting until LTS expiry turns a routine upgrade into a two-major jump, and Angular explicitly supports only one-major-at-a-time migration paths.

Run your a11y test suite after CDK updates specifically. The CDK's whole job is interaction behavior, so regressions show up as focus-order or keyboard-navigation changes that unit tests rarely catch — an end-to-end pass with keyboard-only navigation is the cheapest safety net. Runtime behavior checks like this are also where a DAST pass against a staging build complements static dependency checks: one confirms the version is current, the other confirms the app still behaves.

Supply chain posture

The CDK's provenance is about as strong as npm gets: published by Google's Angular team from a high-visibility monorepo, with no install scripts and a small runtime dependency footprint (essentially parse5 for one entry point and tslib). Known vulnerabilities against @angular/cdk itself are rare to nonexistent in the advisory databases; the realistic risks sit adjacent to it:

• Stale majors. The common finding in audits is not "vulnerable CDK" but "CDK 12 on an app whose Angular version left LTS years ago," which blocks every other frontend security patch. Dependency inventory across an org catches this pattern; an SCA tool such as Safeguard will flag end-of-support framework versions even when no CVE is attached, which is the right way to think about it — EOL is a risk state, not just a housekeeping note.
• Lookalike packages. @angular/cdk is scoped, which kills classic typosquatting, but unscoped packages with "angular cdk" in the name exist on the registry. Anything outside the @angular/ scope claiming to be the CDK deserves scrutiny before install.
• Third-party wrappers. Libraries built on the CDK (@rx-angular/cdk and various component kits) are separate projects with separate maintainers. Evaluate them on their own merits; sharing a name fragment with a Google project transfers zero trust.

When to use the CDK directly vs. Material

If Angular Material's components fit your design, use them and treat the CDK as an implementation detail. Reach for the CDK directly when you are building a bespoke design system and want correct behavior under your own markup and styles: a custom autocomplete on overlay plus a11y, a data grid on cdk-table plus scrolling, a kanban board on drag-drop. The maintenance cost is identical either way — same package, same release train — so the decision is purely about how much visual control you need.

FAQ

What is the @angular/cdk npm package for?

It provides unstyled behavior primitives — overlays, focus management, drag-and-drop, virtual scrolling, breakpoint observation — that Angular Material is built on and that you can use to build custom components with correct accessibility and interaction handling.

Do @angular/cdk and @angular/material versions need to match?

Yes. They ship from the same repository and must share a major version; in practice you should keep them on the identical version and update them together with ng update.

How often should I update the Angular CDK?

Automate patch and minor updates weekly (grouped with your other Angular packages), and take each major within a quarter or so of release while your current major is still in support. Angular majors get roughly 18 months of support including LTS.

Is the Angular CDK safe from a supply chain perspective?

Its provenance is strong — published by the Angular team, scoped package, no install scripts, minimal dependencies. The practical risk is running an out-of-support major that no longer receives fixes, not the package itself being compromised.