Repository navigation
Allow decorators to apply type guards to arguments of the method/function they decorateΒ #50159
Description
Bug Report
π Search Terms
decorators, type guards
π Version & Regression Information
- This is the behavior in every version I tried, and I reviewed the FAQ for entries about decorators
β― Playground Link
Playground link with relevant code
π» Code
class LogPerson {
@isNamePresent
log(person: Person) {
// person.name is guaranteed to be a string due to @isNamePresent decorator, yet error is still thrown
thisNeedsPersonName(person.name)
}
}
interface Person {
name: string | undefined
}
function isNamePresent(target: any, propertyKey: string, descriptor: PropertyDescriptor) {
const originalFunction = descriptor.value;
descriptor.value = function () {
const person = arguments[0];
if (person.name === null || person.name === undefined)
return console.log("Person doesn't have a name");
return originalFunction.apply(this, arguments);
}
}
function thisNeedsPersonName(name: string) {
console.log(`name is ${name}`)
}π Actual behavior
TypeScript throws the error Type 'undefined' is not assignable to type 'string'. when person.name is used as a parameter to a method guarded by the @isNamePresent decorator
π Expected behavior
TypeScript should see the decorator's type guard show the person.name field as only being a string, not string | undefined.
This could be too closely related to function calls not resetting narrowing, in which case, just close this issue. Though I do think it is different enough where it might be possible to be fixed.
Activity
MartinJohns commentedon Aug 3, 2022
Duplicate of #4881. Decorators do not provide the ability to change type information.
Last I read is that the TypeScript will first focus on decorator support (the current implementation is experimental and based on a deprecated proposal), and only then they'll consider looking at mutating types via decorators.
fatcerberus commentedon Aug 3, 2022
This doesn't look like #4881 - the intention doesn't seem to be to change the contract of the class, but rather to add a type check to the implementation. So this is more equivalent to calling
throwIfPersonHasNoName(person)and expecting TypeScript to automatically knowperson.namecan't be undefined afterwards.Barely-Awake commentedon Aug 3, 2022
Yea, exactly. The way I think it might be able to be done is by basically combining the
@isNamePresentfunction with the method below the decorator / the method it is decorating (In my example that'd be log) and then using that to figure out if any types have been narrowed by the decorator.Not sure if it's possible, but I think it'd be a really nice thing to have implemented if it is possible.
[-]Type guards in decorators not updating variable types[/-][+]Allow decorators to apply type guards to arguments of the method/function they decorate[/+]