Angular 22.2 erkennt falsch geschriebene Output-Bindings beim Kompilieren
Serguey Asael Shinder2 Min. LesezeitAngular 22.2.0 ist am 23. September erschienen, zusammen mit Patch-Releases für die Linien 22.1, 21.2 und 20.3. Es ist ein Minor-Release, und die nützlichste Neuerung steckt im Compiler: Die neue Option strictUnclaimedEventNames findet falsch geschriebene Output-Bindings. Ein Event-Binding im Template, das keine Direktive und keine Komponente beansprucht - ein Tippfehler wie (valueChnage) -, kann jetzt beim Build gemeldet werden, statt zur Laufzeit stillschweigend nichts zu tun.
Das Core-Paket erhält programmatische APIs für ErrorBoundary, ein Hilfsmittel zum Testen von Direktiven und die Möglichkeit, den Injector aus einer View- oder Content-Query zu lesen. Der Compiler erlaubt Templates nun den Zugriff auf private Member einer Komponente und korrigiert das CSS-Scoping verschachtelter Selektoren, darunter einen Fall, in dem verschachtelte Regeln unter ::ng-deep fälschlich gekapselt wurden. In Formularen können Signal Forms dauerhaft versteckte Felder deklarieren. Die Typprüfung von @defer-Blöcken mit Schlüssel ist jetzt richtig abgegrenzt, und von mehreren Blöcken geteilte verzögerte Importe werden dedupliziert.
Mehrere Einträge betreffen WebMCP, die vorgeschlagene Browser-Schnittstelle, über die Seiten Aktionen für KI-Agenten beschreiben: Tool-Deklarationen können Annotationen tragen, und aus Signal Forms erzeugte implizite Tools erhalten fest gesetzte Werte für readOnlyHint und untrustedContentHint.
Was das bedeutet
Die Prüfung unbeanspruchter Events adressiert einen der ärgerlichsten Fehler template-basierter Frameworks: Ein Output-Binding mit Tippfehler kompiliert, rendert und feuert nie, und der Fehler fällt erst auf, wenn jemand merkt, dass ein Knopf nichts tut. Daraus einen Kompilierfehler zu machen, ist derselbe Tausch, den Angular vor Jahren mit strikter Template-Typprüfung gemacht hat. Teams, die jene nutzen, sollten auch diese Option einschalten - und in großen Codebasen beim ersten Lauf mit einer Runde Korrekturen rechnen, weil alle vorhandenen Tippfehler auf einmal auftauchen.
Dass Templates private Member lesen dürfen, beseitigt einen alten Grund, Felder nur deshalb öffentlich zu machen, damit ein Template sie nutzen kann - was Komponenten-APIs breiter hielt als nötig. Die WebMCP-Einträge sind klein, zeigen aber, wohin das Framework will: Formularfelder und Seitenaktionen so beschrieben, dass ein automatisierter Agent sie nutzen kann, mit ausdrücklichen Markierungen für lesende Operationen und nicht vertrauenswürdige Inhalte, statt Agenten raten zu lassen.