@andreialecu, as you mentioned, Zach’s PR will address this - there’s very likely no need to change any of your application code.

There is a case that comes up in template type-checking where a directive is generic, and has generic parameter bounds which the template type-checker can’t easily copy (for example, this sometimes happens when a directive does <T extends Foo> and Foo is some interface that isn’t actually exported). In such cases, the compiler has a “deoptimization” that it can do to still properly type-check usages of the directive, just less efficiently than it otherwise could. The Language Service, on the other hand, doesn’t have access to the deoptimization, and previously could not handle checking such directives.

This case was thought to be exceedingly rare, and so we didn’t implement much of a defense against it - the Language Service would give up attempting to check any component that used such a directive.

However, that was naive of us - it turns out this case is less rare than we expected, and such directives do sometimes show up in applications. This kind of code isn’t wrong, it still works at runtime and is still processable by the compiler, but in the Language Service it just can’t be type checked as cleanly. Instead of a hard error, then, we decided to empower the Language Service to still handle such directives by backing off on the generic types, and inferring any instead. This sacrifices a bit of accuracy to allow the directive (and thus the template) to still be understood by the LS.

Falling back to any does affect type inference, but in very minor ways:

• input assignability checks on the directive to inputs which use the generic type may not report errors (but the compiler will still catch them).
• if the generic type flows out from the directive into a context (e.g. with ngTemplateContextGuard), then this type will also be impacted. This case should be very rare, as often such generics are used in more places and thus types are likely to be properly exported. Again, the compiler will process this case correctly regardless.

@z-svoboda-mob - This is purely a limitation of the language service. The compiler itself will use the correct types during compilation. Some generic directives/components require the compiler to make in-line edits to the source by generating a static method which the type check files can import and use to get the correct type. We can’t make this in-line edit in the language service because that would mean editing the file itself.

@zarend is addressing this in #41043 - this will be only an informational diagnostic and the language service will use any for the type rather than exiting and providing no information at all.

@tgfactor For the record, the old version of the language service did not do a better job of determining the correct types of the generics (it’s actually much worse), it just doesn’t produce an error diagnostic. In addition, it is no longer in active development and will be officially deprecated/removed in an upcoming version.

That said, the behavior in the current implementation of the Ivy Language Service is unacceptable because it not only produces the error, but also ends up exiting out of the type checking when it encounters this scenario. @zarend’s PR should be merged this week or next and it will be included whichever weekly release follows that.

FYI, since my initial report, I discovered that these errors were happening due to the “Angular: Enable-experimental-ivy-prompt” and “Angular: Experimental-ivy” checkboxes being selected. Go to the Angular Language Services extension in VSC, and click on the gear for Settings. If both checkboxes are active, simply uncheck them, restart VSC, and the errors should go away.

I do credit them for helping me spot a design flaw in the project, but it was annoying that they were selected and giving me weird errors I had no idea about. Deactivating the experimental options should solve the problem.