Repository navigation
get property return type inferred incorrectly from 'this' type, when other methods exist #61361
Closed as not planned
Description
🔎 Search Terms
get property
get accessor
incorrectly inferred type
incorrectly inferred return type
this
ThisType
🕗 Version & Regression Information
This is the behaviour in every version I tried, and I reviewed the FAQ for entries about 'get accessors'
Before 4.8.4, even stand-alone 'get' properties didn't infer their type correctly.
⏯ Playground Link
💻 Code
/**
* I have a function to capture the type `T` of an object declaration via inference.
* At the same time, I want to provide the function a type `P` that I can inject on the object's 'this' type.
*/
// Given a static type P
function props<P extends object>() {
return {
// Infer the type T of an object, providing P as 'props' on its 'this' type internally.
proto: function <T>(_proto: T & ThisType<T & { props: P }>) {
return _proto as T
}
}
}
/**
* When I declare a 'get' property on the object that returns a value from the injected type `P`, the return type is * inferred correctly:
*/
// Type of 'blah' is 'number'.
const working = props<{ opt: number }>().proto({
get blah() {
return this.props.opt
},
})
/**
* However, when accompanied by any other methods, the return type of `blah` becomes `any`:
*/
// Type of 'blah' should be 'number', but is 'any'.
const broken = props<{ opt: number }>().proto({
foo() {
return 1
},
get blah() {
return this.props.opt
},
})🙁 Actual behavior
By itself, the 'blah' get accessor infers its return type from this.props.opt correctly, but when another method is added to the same object, its type changes to any.
🙂 Expected behavior
The inferred return type of blah get accessor should not be changed by adding a method to the object.
Additional information about the issue
No response
Activity
Andarist commentedon Mar 6, 2025
The problem here is that getters are resolved eagerly even though they might have a context-sensitive dependency on
this. It's not something that methods suffer from even though they might depend onthis(TS playground):That's because they are deferred by nature. So the return type of that
blahmethod can be type-checked whenthistype is already more well-established.A strong duplicate of #47150
A duplicate (in slight disguise) of #49511
Slightly related to #58484
martaver commentedon Mar 7, 2025
What could be more well-established than a static type
{ opt: number }? 😃Thanks for the links, I should have spent longer looking for dupes... do you want me to close this issue and track one of these others ones? Which would be the one to follow?
Andarist commentedon Mar 7, 2025
Tbf, one of the first ones I linked to should be closed in the favor of the other. They look like duplicates to me - but it’s up to Ryan Cavanaugh (@RyanCavanaugh) to decide. So I can’t tell which one you should follow. You can always follow both, they are not noisy anyway :p
RyanCavanaugh commentedon Mar 19, 2025
Omnibus tracked at #47599. An alternative workaround is to write
typescript-bot commentedon Mar 22, 2025
This issue has been marked as "Duplicate" and has seen no recent activity. It has been automatically closed for house-keeping purposes.