Consider `UnwrapPartial<T>` as a way to revert the `Partial<T>` modifier

[porada]

Type description + examples

Let’s consider the following case:

type MyKeyType = 'foo' | 'bar' | 'baz';
type MyObjectType = Record<MyKeyType, number>;

When composing the result from scratch, MyObjectType must be wrapped with Partial.

const result: Partial<MyObjectType> = {};

for (const key of [
	'foo',
	'bar',
	'baz',
] as const satisfies ReadonlyArray<MyKeyType>) {
	result[key] = Math.random();
}

Now that we’ve determined the result, let’s revert the Partial for a clean export.

export const data = result as Required<typeof result>;
//=> const data: Required<Partial<MyObjectType>>

It’s not ideal—we’d expect MyObjectType instead of the lingering type modifiers.

Here’s the same export with Complete, though:

export const data = result as Complete<typeof result>;
//=> const data: MyObjectType

Complete improves DX the same way Simplify does. If there’s consensus around including it, I’d be happy to submit a proper PR.

Type source

type Complete<T> = T extends Partial<infer P> ? P : T;

Search existing types and issues first

• I tried my best to look for it

[sindresorhus]

Another name suggestion: UnwrapPartial

[som-sm]

Couple of pointers:

1. Required<Partial<Something>> is not necessarily Something, it is in fact Required<Something>. For example:

   type Item = {name: string; id?: number}
   type Result = Required<Partial<Item>>; // `Result` is not the same as `Item`
   //   ^? type Result = { name: string; id: number; }

   So, Required<Partial<Something>> is not the same as UnwrapPartial<Partial<Something>>.

2. Also, the suggested implementation will modify non-partial objects as well, like:

   type UnwrapPartial<T> = T extends Partial<infer P> ? P : T;
   
   type NotPartial = { a?: string; b: number };
   type T = UnwrapPartial<NotPartial>;
   //   ^? type T = { a: string; b: number; }
   // Should have been `NotPartial` instead

Umm...not too sure about this type. In your example, you could have simply asserted result to be MyObjectType, like:

export const data = result as MyObjectType;

Maybe if you didn't have access to MyObjectType, you could have unwrapped it, but it still feels very niche. Can you suggest a better use case?

[porada]

Thanks for chiming in.

Required<Partial<Something>> is not the same as UnwrapPartial<Partial<Something>>.

You’re right. That said, there is still value in being able to revert the partial modifier.

Use Cases

Can you suggest a better use case?

Losing access or not having access to the original type is one example.

Another is simply preferring inference over explicit type imports: instead of pulling in a named type just to assert the shape, UnwrapPartial can infer it directly from the partial form, which keeps helpers more generic and decoupled from specific type names.

Both cases are about ergonomics rather than strict necessity. Plenty of type-fest utilities could be called “niche” in that same sense 🙂

Updated Type Definition

type T = UnwrapPartial<NotPartial>;
//   ^? type T = { a: string; b: number }

That’s an argument for returning never when T isn’t a true partial—keeping this utility focused solely on undoing a partial. Here’s the updated type source:

type UnwrapPartial<T> =
    T extends Partial<infer P>
        ? Partial<P> extends T
            ? P
            : never
        : never;

Based on your example:

type NotPartial = { a?: string; b: number };

type T = UnwrapPartial<NotPartial>;
//=> type T = never

type U = UnwrapPartial<Partial<NotPartial>>;
//=> type U = { a?: string; b: number }

[som-sm]

Okay, if you think there are valid use cases, feel free to open up a PR for the same. Also, I guess we should consider adding similar types like UnwrapRequired and UnwrapReadonly.

[porada]

Good call, thanks. I’ll open the PR for UnwrapPartial first and then take a look at the other two. If I’m not mistaken, their definitions should end up looking almost identical.