Add typed overloads to Object.create

[ExE-Boss]

Search Terms

• object.create
• object create
• typed object.create
• typed object create

Suggestion

Change the signatures of Object.create to:

interface ObjectConstructor {
	create<P extends object | null>(proto: P): null extends P ? {} : P;

	create<
		P extends object | null,
		M extends PropertyDescriptorMap = {}
	>(proto: P, properties?: M & ThisType<any>): {
		readonly [
			K in keyof M as M[K] extends { readonly writable: false }
				? K
				: never
		]: M[K] extends Readonly<TypedPropertyDescriptor<infer V>>
			? V
			: any;
	} & {
		-readonly [
			K in keyof M as M[K] extends { readonly writable: true }
				? K
				: never
		]: M[K] extends Readonly<TypedPropertyDescriptor<infer V>>
			? V
			: any;
	} & (null extends P ? {} : P);
}

Use Cases

Getting correct types in code that does:

// `foo` is `any`, because `T` of Object.assign<T, U> is `any`:
const foo = Object.assign(
	// `T` is currently typed as `any`:
	Object.create(null),

	// Only `U` is typed correctly as { bar: number; baz: string }:
	{
		bar: 123,
		baz: 'biz',
	},
);

Examples

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This might need a flag similar to strictBindCallApply, or just done in a separate lib file.
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

Relevant issues

• No way to type an object with null prototype #1108
• Make Javascript intellisense detect inheritance #13206
• Support ES5-style inheritance with Object.create (Salsa) #18609
• RFC: Support __proto__ literal in object initializers #38385
• Add typed return for Object.defineProperties #41424

[DanKaplanSES]

#3865 predates this one but was closed. I'm not sure why it was closed, but it might provide useful information.

@RyanCavanaugh replied:

Mostly we see Object.create being used in code that doesn't really benefit from typing, or with Object.create(null) to create a map object, which is going to require a type assertion anyway.

At present I'd like to create many objects (via literals) of type X, but given that many of the properties are shared, using Object.create makes a lot of sense

Can you post some examples of what this looks like? I can't think of any code that it would meaningfully benefit from a different declaration of Object.create in the scenario you describe.

I'd like to contribute my own use case (Stack Overflow link):

"I'm working on some legacy code I didn't write, trying to refactor it to typescript. ... writing the type definition by hand ... is quite painstaking, especially when the Object.create [property] values ... are complex"

[DanKaplanSES]

@ExE-Boss I'm probably doing something wrong, but the overload isn't giving me the type I would expect when I use it like this.

[lionel-rowe]

Surely this kind of use case is pretty common?

declare const arr: {
    keyLike: string,
    prop1: string,
    prop2: number,
}[]

declare const arbitraryString: string

const lookupObj = Object.assign(
    Object.create(null),
    Object.fromEntries(arr.map(({ keyLike, ...rest }) => [keyLike, rest])),
)

const val = lookupObj[arbitraryString]
// expected type: `{ prop1: string, prop2: number } | undefined`
// actual type: `any`

I guess typing Object.create(null) as {} still wouldn't fix the undefined issue, but that's a separate issue with TS's typing of Object.fromEntries.

Notably, simply defining lookupObj as Object.fromEntries(arr.map(({ keyLike, ...rest }) => [keyLike, rest])) gives val the type { prop1: string, prop2: number }, which is even less correct if arbitraryString happens to be "constructor" or something.

Edit: I know generally Maps are better for this kind of use case, but sometimes a POJO is more convenient, e.g. easy JSON serialization or adding properties with nullish coalescing assignment ??=.