Show completions based on type of inherited / overridden field or method

[benrbray]

Suggestion

TypeScript Version: v5.0.4, tested in TypeScript playground

🔍 Search Terms

• typescript intellisense for overriden method
• typescript intellisense extend interface
• typescript completion for inherited field

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Below, I will use ❌ to indicate the location where intellisense fails to show the expected result.

Scenario 1: Class Overrides Method from Interface

In the code below, there are no intellisense hints available to help fill in the required values for the return type { x: number, y : number} of getLocation.

interface HasLocation {
  getLocation(): { x: number, y: number }
}

class City implements HasLocation {
  getLocation() {
    return {
      ❌ // no suggestions available
    }
  }
}

I would expect the suggestions to include (x:number), (y:number).

Scenario 2: Class Overrides Field from Interface

interface HasLocation {
  location: { x: number, y: number }
}

class City implements HasLocation {
  location = { ❌ /* no suggestions available */ }
}

I would expect the suggestions to include (x:number), (y:number).

Scenario 3: Class Overrides Method from Abstract Class

abstract class HasLocation {
  abstract getLocation(): { x: number, y: number }
}

class City extends HasLocation {
  override getLocation() {
    return {
      ❌ // no suggestions available
    }
  }
}

I would expect the suggestions to include (x:number), (y:number).

Scenario 4: Class Overrides Field from Abstract Class

abstract class HasLocation {
  abstract location: { x: number, y: number }
}

class City extends HasLocation {
  location = { ❌ /* no suggestions available */ }
}

I would expect the suggestions to include (x:number), (y:number).

Working Scenario: Interface Instance

By comparison, if we declare a variable to have type HasLocation, intellisense works as expected:

interface HasLocation {
  getLocation(): { x: number, y: number }
}

const origin: HasLocation = {
    getLocation() {
        return {
            // ✅ suggestions: (x:number), (y:number)
        }
    }
}

📃 Motivating Example

See the scenarios above. This feature would make it easier for users of a library to correctly implement interfaces and extend abstract classes exposed by the library, without the need to directly check the documentation.

💻 Use Cases

I ran into this issue while building a "community plugin" system for a TypeScript library. The idea is:

• the library will define an Extension interface (or abstract class)
• extension authors make a class CustomExtension implements Extension (or class CustomExtension extends Extension), with rich intellisense hints available for filling in the required values

If needed I can provide further details about the motivation, but I think the scenarios above are already clear enough. As a workaround, for now, I can structure my code similar to the "Working Scenario" listed above and require the user to pass in an ExtensionConfig instance to the Extension constructor. This isn't terrible, but adds some complexity.

[MartinJohns]

Duplicate of #32082.

The reason why suggestion is not working in your examples is because the return type of the method is not known. The return type is inferred based on your implementation, then checked for compatibility with your interface / base class.

[benrbray]

Thanks for the link to the duplicate issue, it does look very similar.

The reason why suggestion is not working in your examples is because the return type of the method is not known. The return type is inferred based on your implementation, then checked for compatibility with your interface / base class.

That's exactly what I would like to see changed -- if there is no explicit return type annotation, the return type should be inferred using the type from the original interface / base class. Already, TypeScript tells you if you return the wrong type, so it would be great if it could help you write the correct type the first time.

[MartinJohns]

That's exactly what I would like to see changed -- if there is no explicit return type annotation, the return type should be inferred using the type from the original interface / base class.

And that's exactly what #32082 is about.

[RyanCavanaugh]

I think this is in principle separable from #32082, since completion behavior can and does diverge from type system behavior.