Description
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 codeThis wouldn't change the runtime behavior of existing JavaScript codeThis could be implemented without emitting different JS based on the types of the expressionsThis 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
(orclass 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.
Activity
MartinJohns commentedon Apr 15, 2023
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 commentedon Apr 15, 2023
Thanks for the link to the duplicate issue, it does look very similar.
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 commentedon Apr 15, 2023
And that's exactly what #32082 is about.
RyanCavanaugh commentedon Apr 17, 2023
I think this is in principle separable from #32082, since completion behavior can and does diverge from type system behavior.