Repository navigation
Object.values and Object.entries return type any when passing an object defined as having number keys #26010
Description
TypeScript Version: 3.1.0-dev.20180727
Search Terms: Object.values Object.entries wrong type inference any
Code
interface I {
[x: number]: string | null;
}
const o: I = { 5: 'test', 8: null };
const v = Object.values(o);Expected behavior: Type of v should be (string | null)[].
Actual behavior: Type of v is any[].
Playground Link: Typescript Playground doesn't support Object.values().
Related Issues: #21089
This bug seems to occur due to the type definitions for ObjectConstructor, which used to include the possibility of number keys in their type signatures. I'm not sure exactly why this was changed to ArrayLike to resolve the related issue I linked (this is the exact PR), but it breaks the type inference on the results of Object.values() and Object.entries() when passing it a type defined as having number keys.
interface ObjectConstructor {
/**
* Returns an array of values of the enumerable properties of an object
* @param o Object that contains the properties and methods. This can be an object that you created or an existing Document Object Model (DOM) object.
*/
values<T>(o: { [s: string]: T } | ArrayLike<T>): T[];
// ...
}This type signature used to be values<T>(o: { [s: string]: T } | { [n: number]: T }): T[], and with this older signature, the example code properly types the result of Object.values().
Activity
mhegazy commentedon Jul 27, 2018
It was originally defined to allow numeric index signatures, but that broke enums (#21089 as you have referenced earlier). I do not think there is a good solution that does not break something.
philraj commentedon Jul 30, 2018
What is the reason for the wrong type inference on enums when the type signature allows numeric indexes?
[edit] Removed invalid code example.
philraj commentedon Jul 31, 2018
In #21089 you wrote:
Is this too dangerous to attempt? Shouldn't enums have that by default, since numeric enums have the property of reverse mappings? I don't understand the following discrepancy:
quicksnap commentedon Feb 21, 2019
I just encountered this
anyinference when migrating some types that were used withObject.entries, resulting in returning[string, any][].We aim to have no
anyin our codebase, as it leads to avoidable runtime errors. If there's no resolution to this, we'll likely enforce usage of a wrapper utility to provide better typings.Would love to see progress on this.
Thank you to the TypeScript team for all your hard work! <3