You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Language Service: TypeParameter.constraint is lazily calculated, but does not have an accessor function #5689
Because of this, I have to go through this awkward motion every time:
functiongetConstraint(type: ts.TypeParameter){// This call will cause the typechecker to resolve properties, as well as a bunch of other information// about the type (such as generic constraints), but we don't actually need its result right now.type.getProperties();returntype.constraint;}
For some members (such as "properties" - above), there is an accessor function, which I can use to be sure the data is up to date. Another category of members don't need an accessor function, because they are calculated eagerly, and so are "always there".
But there is this third category of members, which fall through the gap. One example is TypeParameter.constraint. Another is InterfaceTypeWithDeclaredMembers.declaredProperties. There are probably more, but I haven't come across them yet.
It would solve half the issue: now I can use that function to get the value while making sure it's calculated. But that is assuming that I know which function to use. If I was just exploring the API, I would see the constraint property and wouldn't think twice about just using it. It will be only after hours of debugging and googling (and possibly finding this issue) that I would gain the necessary knowledge.
So to solve the other half, the property needs to be hidden. But I'm not sure if it will break something somewhere.
Agreed. so what we need to do is 1. expose the getConstraintOfTypeParameter on the TypeChecker interface, 2, add Type.getConstraint() method on the TypeObject class, and 3, mark type.constraint as internal.
3 is a breaking change, so not sure if/when we can do it. but other ones should be doable.
Activity
mhegazy commentedon Dec 3, 2015
Would exposing
getConstraintOfTypeParameteron the API address the issue?fsoikin commentedon Dec 3, 2015
It would solve half the issue: now I can use that function to get the value while making sure it's calculated. But that is assuming that I know which function to use. If I was just exploring the API, I would see the
constraintproperty and wouldn't think twice about just using it. It will be only after hours of debugging and googling (and possibly finding this issue) that I would gain the necessary knowledge.So to solve the other half, the property needs to be hidden. But I'm not sure if it will break something somewhere.
mhegazy commentedon Dec 3, 2015
Agreed. so what we need to do is 1. expose the getConstraintOfTypeParameter on the TypeChecker interface, 2, add Type.getConstraint() method on the TypeObject class, and 3, mark type.constraint as internal.
3 is a breaking change, so not sure if/when we can do it. but other ones should be doable.
mhegazy commentedon Dec 3, 2015
PRs are definitely welcomed.
RyanCavanaugh commentedon Aug 18, 2026
This was fixed via #20137