@angular/core

@angular/core is the foundation package of the Angular platform, providing the class infrastructure for components, directives, and view hierarchies, along with the dependency injection system, change detection engine, and signal-based reactivity that every Angular application is built on. It is maintained by Google alongside the rest of the Angular monorepo and ships in lockstep with the compiler, forms, router, and other first-party packages.

Beyond wiring up components and services, @angular/core defines the decorators (@Component, @Injectable, @Input, etc.) that give Angular’s compiler the metadata it needs, and includes lower-level infrastructure for hydration, internationalization, testability, and debugging that most application code never touches directly but depends on implicitly. Its ivy-based renderer (render3) compiles templates to highly optimized instructions rather than interpreting them at runtime.

As of the 2020s Angular has moved decisively toward a signals-first reactivity model layered on top of its historical zone.js-based change detection, letting teams adopt fine-grained reactive state incrementally without a rewrite. The package is a required peer dependency for virtually every other package in the Angular ecosystem (router, forms, animations, PWA/service-worker support, and the CLI’s schematics).

What You Get

• Component and directive infrastructure with decorators (@Component, @Directive, @Injectable) that the Angular compiler consumes to generate optimized render instructions
• A hierarchical dependency injection system (Injector, InjectionToken, inject()) supporting tree-shakable providers and environment-level injectors
• Signal-based reactivity (signal(), computed(), effect(), linkedSignal()) alongside the traditional zone.js change-detection model, so teams can migrate incrementally
• The Ivy renderer (render3) that compiles templates into fine-grained update instructions instead of interpreting a virtual DOM at runtime
• Built-in hydration support for reducing client-side re-rendering work after server-side rendering
• Schematics-based migrations (e.g. signal-input and signal-queries migrations) that automate large-scale codemods across an app when APIs evolve

Common Use Cases

• Enterprise single-page applications - large internal or customer-facing apps that need strict typing, DI-driven testability, and a stable long-term-support release cadence
• Design-system-driven component libraries - teams building a shared component library across many Angular apps rely on @Component/@Directive metadata and DI for consistent, swappable services
• Server-side rendered and hydrated apps - apps paired with Angular SSR/@angular/ssr use core’s hydration APIs to avoid re-rendering the DOM on the client
• Incremental signal adoption - existing zone.js-based Angular codebases introducing signal()/computed() state in specific components without a full rewrite
• Schematic-driven codemods - large codebases using Angular’s built-in migration schematics to automate framework upgrades across hundreds of files

Under The Hood

Architecture The package is organized as a layered runtime: src/di implements the hierarchical injector (r3_injector.ts, create_injector.ts) that every other layer depends on for constructing services and components; src/render3 (181 source files) is the Ivy renderer, compiling @Component-decorated classes into low-level view-update instructions consumed at instructions/component_ref.ts, with context_discovery.ts and view managing the live view tree; src/change_detection layers a differs mechanism and a scheduling subsystem on top of render3 to decide when views re-check; and src/hydration (annotate/cleanup/event_replay) reconciles server-rendered DOM against this same view tree without re-rendering it. Signals live in a separate primitives/signals package and are consumed by render3 and the public authoring API (input(), model(), linkedSignal()), so the reactive graph sits alongside, rather than inside, the zone.js-driven change-detection path — the two coexist deliberately so consumers can adopt signals incrementally. Changing the injector or render3’s instruction format would ripple through effectively every Angular package in the monorepo, since they’re both consumed as peer infrastructure rather than optional utilities.

Tech Stack Written entirely in TypeScript (87.6% of repo bytes) and built with Bazel (BUILD.bazel, MODULE.bazel) rather than a conventional bundler, reflecting the monorepo’s Google-internal build heritage; the published npm package’s only runtime dependency is tslib, with @angular/compiler, rxjs, and zone.js declared as (partly optional) peer dependencies rather than bundled. The compiler pipeline (ivy/render3) is what turns decorator metadata into JIT- or AOT-compiled instructions, and schematics (schematics/collection.json) hook into the Angular CLI/ng update toolchain for automated migrations. context7.json and AGENTS.md at the repo root indicate active investment in AI-assisted tooling integration alongside the traditional Angular CLI/language-service ecosystem.

Code Quality Testing is extensive and mandatory for merges: 240+ _spec.ts files plus 18 .spec.ts files under packages/core alone, run through Bazel-orchestrated CI (.github/workflows/ci.yml, pr.yml) alongside dedicated benchmark, SauceLabs cross-browser, and internal Google test jobs. Strict TypeScript typing is used throughout (no any-heavy public APIs), errors are surfaced through a typed RuntimeError/RuntimeErrorCode system (errors.ts) with dedicated error-detail documentation URLs rather than bare thrown strings, and Prettier (.prettierrc) enforces consistent formatting repo-wide. The schematics/migrations directory ships its own dedicated spec suites, meaning even codemods carry their own test coverage.

What Makes It Unique Angular’s core departs from most component frameworks by compiling templates ahead-of-time into direct instruction sets (Ivy) rather than diffing a virtual DOM, and by running two reactivity models side by side — zone.js-based automatic dirty-checking and an explicit, fine-grained signals graph — so large existing codebases can adopt signals file-by-file instead of via a breaking rewrite. Its dependency-injection system is unusually deep for a frontend framework, supporting per-route, per-component, and environment-scoped injectors with tree-shakable providers, and its schematics-driven migration tooling (automated codemods for signal inputs, signal queries, and more) is a level of first-party upgrade automation few other frontend frameworks attempt at this scale.