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

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.

Reproduziere die vier Klassen- und Schnittstellenszenarien im TypeScript Playground und vergleiche sie mit dem funktionierenden Objektliteral-Szenario. Beginne damit, das Completion-Verhalten von TypeScript für überschriebene Methoden und Felder nachzuverfolgen; abgeschlossen ist die Aufgabe, wenn Completions in jedem aufgeführten Fall den geerbten Rückgabe- oder Feldtyp offenlegen, ohne die Runtime-Ausgabe zu ändern.