noImplicitAny checks don't work for a setter parameter of Object.defineProperty

[falsandtru]

TypeScript Version:

master

Code

Object.defineProperty({}, '', {
  set(a) { // a is an implicit any type
  }
});

Expected behavior:

error

Actual behavior:

pass

[mhegazy]

it gets a contextual type from the declaration, see https://github.com/Microsoft/TypeScript/blob/master/lib/lib.d.ts#L81.

we could change the definition of defineProperty to use TypedPropertyDescriptor instead of PropertyDescriptor, that will make your setter argument inferred from declaration, so it will be {} and not any, which would be closer to an error. but that would be a breaking change.

[mhegazy]

so just to be clear, the reported behavior is expected given the lib.d.ts definition. if there is anything to do is to change the definition in lib.d.ts

[falsandtru]

related: #8373

[kitsonk]

I don't think they are actually related. It is being properly contextually typed as any. What I think @mhegazy is suggesting is that it might be worth this being implemented in lib.d.ts in the future, as it stands at the moment it will always be non-implicit any because of the contextual typing:

interface PropertyDescriptor<T> {
    configurable?: boolean;
    enumerable?: boolean;
    value?: T;
    writable?: boolean;
    get? (): T;
    set? (v: T): void;
}

interface ObjectConstructor {
    defineProperty<T>(o: any, p: string, attributes: PropertyDescriptor<T>): any;
}

I suspect there are a few other places too that would need to be adjusted.

[mhegazy]

As noted earlier, there is a context type passed through, and that suppresses the noImplicitAny errors. you can get a better behavior by defining an extra overload of define property as:

interface ObjectConstructor {
    defineProperty<T>(o: any, p: string, attributes: TypedPropertyDescriptor<T>): any;
}

it is not clear there is much value in changing the lib.d.ts definitions for everybody though.