Angular 22.2 can flag misspelled output bindings at compile time
Serguey Asael Shinder2 min readAngular 22.2.0 was released on 23 September, alongside patch releases for the 22.1, 21.2 and 20.3 lines. It is a minor release, and its most useful addition is in the compiler: a new strictUnclaimedEventNames option catches misspelled output bindings. An event binding in a template that no directive or component claims - a typo such as (valueChnage) - can now be reported at build time instead of silently doing nothing at run time.
The core package gains programmatic APIs for ErrorBoundary, a utility for testing directives, and the ability to read the Injector from a view or content query. The compiler now lets templates access private component members, and fixes CSS scoping for nested selectors, including a case where nested rules under ::ng-deep were encapsulated when they should not have been. In forms, signal forms can declare fields that are permanently hidden. Type-checking of keyed @defer blocks is now scoped correctly, and deferred imports shared by several blocks are deduplicated.
Several entries relate to WebMCP, the proposed browser interface for exposing page actions to AI agents: tool declarations can carry annotations, and implicit tools generated from signal forms get hard-coded readOnlyHint and untrustedContentHint values.
What it means
The unclaimed-event check addresses one of the more frustrating bugs in template-driven frameworks: an output binding with a typo compiles, renders and never fires, and the failure is found only when someone notices a button does nothing. Turning that into a compile error is the same trade Angular made years ago with strict template type-checking, and teams that adopted that should enable this option too - expect a round of fixes on first run in a large codebase, since every existing typo will surface at once.
Allowing templates to read private members removes a long-standing reason to make fields public only so a template could use them, which kept component APIs wider than they needed to be. The WebMCP entries are small but show where the framework expects to go: form fields and page actions described in a way an automated agent can use, with explicit markers for read-only operations and untrusted content rather than leaving agents to guess.