Some of the tests that use injector.get failed because of its last overload signature.

If we pass a class without constructor arguments, the right overload signature will be matched. On the other hand, when we pass a class with constructor arguments, the expected signature will be skipped and the last one (with token: any) will be matched. However, if we comment out the last signature, the right one will be matched. 👀

I reported this behavior here: microsoft/TypeScript#51899
Simplified reproduction:

type Type<T> = new (...args: any[]) => T;

function inject<T>(t: Type<T>): T;
function inject(t: any): any; // comment out this line => the type of `c2` will be `ClassWithCtorArgs`
function inject(t: any): any {
    return t;
}

class Class {}

class ClassWithCtorArgs {
    constructor(x: number) {}
}

// type: Class ✅
const c1 = inject(Class);

// type: any ❌
const c2 = inject(ClassWithCtorArgs);

Before this PR, the right signature was matched because of the { prototype: T } that was part of the AbstractType interface. However { prototype: T } breaks type inference for classes with generics.

Given that ClassWithCtorArgs is much more common than classes with generics, I this feels like a regression in the majority of cases. Adding the blocked label until this issue is resolved.

Given that ClassWithCtorArgs is much more common than classes with generics, I this feels like a regression in the majority of cases. Adding the blocked label until this issue is resolved.

Yes, for sure. Another solution could be to remove the overload signature with token: any in v16. This signature is currently deprecated btw.

Hi @pkozlowski-opensource, @atscott 👋

Have you considered removing deprecated signatures with token: any in v16? 👀

@markostanimirovic We will not have time to work on a migration for v16.

Hi everyone!
With inject becoming more popular, I'm seeing this issue occurring more and more often. Any news about this PR getting merged? 😊 Thanks!

I stumbled upon this today. Hopefully this PR gets merged soon!

Per discussions in this PR, the fix here is a regression in the more common cases. The ideal path forward is to remove the overload with token: any

I think I misunderstood the comment history here. The correct fix requires this change and the removal of the deprecated any overload. Is that correct @markostanimirovic?

I think I misunderstood the comment history here. The correct fix requires this change and the removal of the deprecated any overload. Is that correct @markostanimirovic?

Yes 👍

@markostanimirovic

Would it be possible to use infer?

#53894 (comment)

Another possible option is to add the current definition of AbstractType as an overload before the deprecated any:

type Type<T> = new (...args: any[]) => T;

function inject<T>(t: Type<T>): T;
function inject<T>(t: Function & {prototype: T}): T // <- new
function inject(t: any): any;
function inject(t: any): any {
    return t;
}

class ClassWithCtorArgs {
    constructor(x: number) {}
}

// infers ClassWithCtorArgs ✅
const c2 = inject(ClassWithCtorArgs);

The obvious downside is that it adds yet another overload that needs to be removed eventually, and unlike any it can't be marked as deprecated, since that will incorrectly flag usages like ClassWithCtorArgs which will continue working after its removal.

Any news concerning this? It makes some signatures really long

#60202 was submitted to remove the any overload so presumably this should address the regression mentioned in #48408 (comment). Will run global internal tests to see how breaking this change is

Unfortunately this is way too breaking, components with elementRef = inject(ElementRef); now return unknown and this breaks accesses like component.instance.elementRef.nativeElement.

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}