Skip to content

Can't infer from this type on static class method call in JS Doc #50952

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
dead-claudia opened this issue Sep 26, 2022 · 4 comments · Fixed by #51149
Closed

Can't infer from this type on static class method call in JS Doc #50952

dead-claudia opened this issue Sep 26, 2022 · 4 comments · Fixed by #51149
Labels
Bug A bug in TypeScript Domain: JSDoc Relates to JSDoc parsing and type generation Help Wanted You can do this
Milestone

Comments

@dead-claudia
Copy link

Bug Report

🔎 Search Terms

  • js inference
  • javascript inference

🕗 Version & Regression Information

  • This is the behavior in every version I tried, and I reviewed the FAQ for entries about differing type inference for JS and TS

💻 Code

JavaScript:

/** @template R */
export class Action {
    /**
     * @returns {R}
     */
    action() {
        throw new Error("This method is abstract!")
    }

    /**
     * @template {new () => Action<any>} C
     * @this {C}
     * @return {C extends new () => Action<infer T> ? T : never}
     */
    static run() {
        return new this().action()
    }
}

/** @extends {Action<number>} */
export class Foo extends Action {
    action() {
        return 1
    }
}

const handle = Foo.run()
Compiler Options
{
  "compilerOptions": {
    "strict": true,
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "strictBindCallApply": true,
    "noImplicitThis": true,
    "noImplicitReturns": true,
    "alwaysStrict": true,
    "esModuleInterop": true,
    "checkJs": true,
    "allowJs": true,
    "declaration": true,
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "target": "ES2017",
    "jsx": "react",
    "module": "ESNext",
    "moduleResolution": "node"
  }
}

Playground Link: Provided

TypeScript:

export abstract class Action<R> {
    action(): R {
        throw new Error("This method is abstract!")
    }

    static run<C extends new () => Action<any>>(
        this: C,
    ): C extends new () => Action<infer T> ? T : never {
        return new this().action()
    }
}

export class Foo extends Action<number> {
    action() {
        return 1
    }
}

const handle = Foo.run()
Output
export class Action {
    action() {
        throw new Error("This method is abstract!");
    }
    static run() {
        return new this().action();
    }
}
export class Foo extends Action {
    action() {
        return 1;
    }
}
const handle = Foo.run();
Compiler Options
{
  "compilerOptions": {
    "strict": true,
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "strictBindCallApply": true,
    "noImplicitThis": true,
    "noImplicitReturns": true,
    "alwaysStrict": true,
    "esModuleInterop": true,
    "declaration": true,
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "target": "ES2017",
    "jsx": "react",
    "module": "ESNext",
    "moduleResolution": "node"
  }
}

Playground Link: Provided

🙁 Actual behavior

The inferred type for handle to in the JS version is any, and the --noImplicitAny option is not respected.

🙂 Expected behavior

The inferred type for handle to be number for both, as the types are fully equivalent.

@dead-claudia dead-claudia changed the title In JS files only, when the return value is extracted from an inner instance of a generic type, the type inferred is any and this inferred any fails to generate any noImplicitAny errors In JS files only, when the return value is extracted from an inner instance of a generic type whose underlying value is passed as this, the type inferred is any and this inferred any fails to generate any noImplicitAny errors Sep 26, 2022
@dead-claudia
Copy link
Author

Did this get missed?

@RyanCavanaugh RyanCavanaugh added Bug A bug in TypeScript Help Wanted You can do this labels Oct 7, 2022
@RyanCavanaugh RyanCavanaugh added this to the Backlog milestone Oct 7, 2022
@RyanCavanaugh RyanCavanaugh added the Domain: JSDoc Relates to JSDoc parsing and type generation label Oct 7, 2022
@RyanCavanaugh RyanCavanaugh changed the title In JS files only, when the return value is extracted from an inner instance of a generic type whose underlying value is passed as this, the type inferred is any and this inferred any fails to generate any noImplicitAny errors Can't infer from this type on static class method call in JS Doc Oct 7, 2022
@RyanCavanaugh
Copy link
Member

This can be vastly simplified:

export class Test {
    /**
     * @template C
     * @this {C}
     * @return {C}
     */
    static test() {
        return this;
    }
}
// p: any, should be p: typeof Test
const p = Test.test();

@dead-claudia
Copy link
Author

@RyanCavanaugh Yeah, I tried simplifying it further, but wasn't quite able to get it that simple. 😅

@a-tarasyuk
Copy link
Contributor

@RyanCavanaugh It seems that the problem is not limited to static methods.

export class Test {
    /**
     * @template T
     * @this {T}
     * @return {T}
     */
    test() {
        return this;
    }
}

const t = new Test();
const p = t.test(); // any?
p;

Playground

I think it's because getThisTypeOfSignature doesn't try to resolve the @this tag. Do we need to handle the The_this_context_of_type_0_is_not_assignable_to_method_s_this_of_type_1_2684 error in this case? Since getTypeOfSymbol(signature.thisParameter) can return instantiated this type, I don't know how we can do that for @this tag...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug A bug in TypeScript Domain: JSDoc Relates to JSDoc parsing and type generation Help Wanted You can do this
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants