Add `SetRequiredDeep` type #939

hugomartinet · 2024-08-12T17:18:22Z

Closes #796

This pull request adds a new SetRequiredDeep which, like SetRequired, allows to make one or several keys in a model required. It adds the possibility to select nested keys by specifying their path.

Example

import type {SetRequiredDeep} from 'type-fest';

type Foo = {
	a?: number;
	b?: string;
	c?: {
		d?: number
	}[]
}

type SomeRequiredDeep = SetRequiredDeep<Foo, 'a' | `c.${number}.d`>;
// type SomeRequiredDeep = {
// 	a: number; // Is now required
// 	b?: string;
// 	c: {
//    d: number // Is now required
//  }[]
// }

source/set-required-deep.d.ts

Emiyaaaaa · 2024-08-14T09:14:35Z

Can this feature be added on SetRequired instead of a new type? just move code into SetRequired

@sindresorhus how about you think?

sindresorhus · 2024-08-17T11:56:32Z

The problem with doing both shallow and deep in a single method is that the deep logic affects the performance even if you don't need deep. This was the case for Simplify, where we had to split it out into a SimplifyDeep version.

source/set-required-deep.d.ts

test-d/set-required-deep.ts

source/set-required-deep.d.ts

Emiyaaaaa · 2024-08-21T02:36:07Z

Need to resolve all conversation

hugomartinet · 2024-08-21T10:09:46Z

Need to resolve all conversation

Done

test-d/set-required-deep.ts

source/set-required-deep.d.ts

Beraliv · 2024-10-29T12:09:51Z

@sindresorhus @hugomartinet I'll have a look at your PR later today or tomorrow

source/set-required-deep.d.ts

Beraliv · 2024-10-30T22:17:12Z

test-d/set-required-deep.ts

+
+// Set nested key to required
+declare const variation1: SetRequiredDeep<{a?: number; b?: {c?: string}}, 'b.c'>;
+expectType<{a?: number; b: {c: string}}>(variation1);


You haven't specified 'b' | 'b.c', therefore the expected behaviour should be expectType<{a?: number; b?: {c: string}}>(variation1); (b is still optional)

Same below

Thanks for this remark. I actually did this on purpose, in my mind I thought that this is what we want.

Since SetRequired<..., 'b.c'> would mean that we want b.c to always be defined, hence we also need b to always be defined. Do you disagree ?

The reason is that I thought it would be fastidious when having nested objects with many levels. Writing SetRequired<..., 'a.b.${number}.c'> is lighter than writing SetRequired<..., 'a' | 'a.b' | 'a.b.${number}' | 'a.b.${number}.c'>.

What do you think ? If you're confident on making only the nested key required I can work on that again 😀

Beraliv · 2024-10-30T22:19:33Z

test-d/set-required-deep.ts

+
+// Set key inside array to required
+declare const variation7: SetRequiredDeep<{a?: Array<{b?: number}>}, `a.${number}.b`>;
+expectType<{a: Array<{b: number}>}>(variation7);


Similar here (and below), the only required path `a.${number}.b` is specified, not 'a' | `a.${number}.b`, therefore the expected behaviour should be expectType<{a?: Array<{b: number}>}>(variation7);

Beraliv · 2024-10-30T22:24:24Z

@hugomartinet I left my thoughts, I don't think it's ready because of a bug in the implementation (specified in my 2 comments where exactly), but I will leave it up to you (cc @sindresorhus)

hugomartinet · 2024-11-28T19:14:12Z

@hugomartinet I left my thoughts, I don't think it's ready because of a bug in the implementation (specified in my 2 comments where exactly), but I will leave it up to you (cc @sindresorhus)

@Beraliv I pushed a correction, I think I managed to take into account the expected behaviour you mentioned, thanks for pointing it out!

hugomartinet · 2024-12-13T16:58:12Z

@sindresorhus @Beraliv How should we proceed on this?
Do you still have comments and suggestions?

Beraliv · 2024-12-13T23:25:03Z

@hugomartinet thank you for your patience! If it waits, I'll leave my comments by the end of the year (next 2 weeks). If not, proceed with what you have and I'll raise bugs later if I find anything unexpected

som-sm

@hugomartinet The current implementation seems to fail in the following cases:

 type T1 = SetRequiredDeep<{ a: 1; b: { c?: 1 } }, 'b.c'>;
 //   ^? type T1 = { a: 1; b?: { c: 1 } }

Shouldn't make b optional.

 type T1 = SetRequiredDeep<{ a: 1; readonly b: { c?: 1 } }, 'b.c'>;
 //   ^? type T1 = { a: 1; b?: { c: 1 } }

Doesn't preserve the readonly modifier on b.

 type T1 = SetRequiredDeep<{ a: 1; readonly b: { c?: 1 } | number }, 'b.c'>;
 //   ^? type T1 = { a: 1; b?: { c: 1 } }

Doesn't preserve the | number on b.

 type T1 = SetRequiredDeep<{ 0: 1; 1: { 2?: string } }, '1.2'>;
 //   ^? type T1 = {0: 1; 1: {2?: string}}

Doesn't work with number keys.

Beraliv · 2024-12-26T13:08:11Z

@som-sm thank you for your summary of issues, this is exactly what I experienced when I was testing changes in October. @hugomartinet can you add unit tests for all scenarios I and @som-sm mentioned and fix those? Thank you

hugomartinet · 2024-12-27T21:40:15Z

@som-sm @Beraliv

Thanks for the update, I added these test cases and fixed them 👍

som-sm · 2024-12-29T12:54:22Z

@hugomartinet Looks like it's not working properly with index signatures:

type Test = SetRequiredDeep<{[x: string]: unknown; a?: number}, 'a'>;
//   ^? {[x: string]: unknown; [x: number]: unknown;}

Should have returned {[x: string]: unknown; a: number;} instead.

And the implementation seems to have gotten really complicated, here's a much simpler implementation that passes all the existing tests and also works with index signatures.

export type SetRequiredDeep<Type, KeyPaths extends Paths<Type>> =
Type extends NonRecursiveType
	? Type
	: SimplifyDeep<(
		{[K in keyof Type as K extends (KeyPaths | StringToNumber<KeyPaths & string>) ? K : never]-?: Type[K]} extends infer RequiredPart
			? keyof RequiredPart extends never ? unknown : RequiredPart
			: never) & {
		[K in keyof Type]: Extract<KeyPaths, `${K & (string | number)}.${string}`> extends never
			? Type[K]
			: SetRequiredDeep<Type[K], KeyPaths extends `${K & (string | number)}.${infer Rest extends Paths<Type[K]>}` ? Rest : never>
	}>;

type StringToNumber<Keys extends string> = Keys extends `${infer N extends number}` ? N : never;

@hugomartinet WDYT? Do you see any cases where the above implementation might fail?

hugomartinet · 2024-12-29T16:25:27Z

@hugomartinet Looks like it's not working properly with index signatures:

type Test = SetRequiredDeep<{[x: string]: unknown; a?: number}, 'a'>;
//   ^? {[x: string]: unknown; [x: number]: unknown;}

Should have returned {[x: string]: unknown; a: number;} instead.

And the implementation seems to have gotten really complicated, here's a much simpler implementation that passes all the existing tests and also works with index signatures.

export type SetRequiredDeep<Type, KeyPaths extends Paths<Type>> =
Type extends NonRecursiveType
	? Type
	: SimplifyDeep<(
		{[K in keyof Type as K extends (KeyPaths | StringToNumber<KeyPaths & string>) ? K : never]-?: Type[K]} extends infer RequiredPart
			? keyof RequiredPart extends never ? unknown : RequiredPart
			: never) & {
		[K in keyof Type]: Extract<KeyPaths, `${K & (string | number)}.${string}`> extends never
			? Type[K]
			: SetRequiredDeep<Type[K], KeyPaths extends `${K & (string | number)}.${infer Rest extends Paths<Type[K]>}` ? Rest : never>
	}>;

type StringToNumber<Keys extends string> = Keys extends `${infer N extends number}` ? N : never;

@hugomartinet WDYT? Do you see any cases where the above implementation might fail?

Looks good to me, thanks for the simplification

som-sm · 2024-12-29T16:47:20Z

Looks good to me, thanks for the simplification

@hugomartinet Great! I'll go ahead and update the PR then.

Although, most likely the following bit can also be simplified further to just be the mapped type:

{[K in keyof Type as K extends (KeyPaths | StringToNumber<KeyPaths & string>) ? K : never]-?: Type[K]} extends infer RequiredPart
	? keyof RequiredPart extends never ? unknown : RequiredPart
	: never

Currently, if I replace the above bit with just the mapped type:

{[K in keyof Type as K extends (KeyPaths | StringToNumber<KeyPaths & string>) ? K : never]-?: Type[K]}

It fails to preserve the structure of arrays for some reason. So, SetReadonlyDeep<{b: Array<{c?: 1}>}>, `b.${number}.c`> doesn't return {b: Array<{c: 1}>}, instead it unwraps the array. Ideally this shouldn't have happened because this case evaluates to: {} & {b: {} & Array<{c: 1} & {c?: 1}>} which should simplify down to {b: Array<{c: 1}>}, but for some reason it doesn't. For now, I'm replacing the empty objects with unknown to make it work.

Will have to spend more time to understand what's going wrong, but I guess it's fine for now.

hugomartinet · 2024-12-29T20:02:26Z

Thanks @som-sm!

What are the next steps for this PR?

Beraliv · 2024-12-29T23:02:47Z

@som-sm @hugomartinet I'm having a last look at the PR, please bear with me

Beraliv · 2024-12-29T23:36:03Z

From test perspective, everything works as expected, great work @hugomartinet & @som-sm!

Beraliv · 2024-12-29T23:46:01Z

It fails to preserve the structure of arrays for some reason. So, SetReadonlyDeep<{b: Array<{c?: 1}>}>, b.${number}.c> doesn't return {b: Array<{c: 1}>}, instead it unwraps the array. Ideally this shouldn't have happened because this case evaluates to: {} & {b: {} & Array<{c: 1} & {c?: 1}> which should simplify down to {b: Array<{c: 1}>}, but for some reason it doesn't. For now, I'm replacing the empty objects with unknown to make it work.

Very interesting investigation, @som-sm! I tried to follow the path around SimplifyDeep: when I remove SimplifyDeep and your workaround with unknown,

SetRequiredDeep<{ b: Array<{ c?: 1 }> }, `b.${number}.c`> is evaluated as:

{} & {
    b: {} & ({
        c: 1;
    } & {
        c?: 1;
    })[];
}

All the next statements evaluated correctly:

// { c: 1}[]
type B1 = SimplifyDeep<{} & Array<{ c: 1 }>>;

// {b: {c: 1}[]}
type B2 = SimplifyDeep<{
	b: ({
		c: 1;
	} & {
		c?: 1;
	})[];
}>;

// {b: {c: 1}[]}
type B3 = SimplifyDeep<
	{} & {
		b: {} & ({
			c: 1;
		} & {
			c?: 1;
		})[];
	}
>;

But when I call SimplifyDeep<A>, it again unwraps arrays. I believe it can be a known quirk of TypeScript or simply a bug. I searced issues in TypeScript repo but I cannot find anything.

Beraliv

@hugomartinet @som-sm amazing work, thanks both of you for addressing the issues, it LGTM now!

som-sm · 2024-12-30T06:29:49Z

@Beraliv Thanks for the detailed breakdown.

I believe it can be a known quirk of TypeScript or simply a bug.

I think I've managed to find a simpler reproduction of this issue:

import {Simplify} from "type-fest";

type T1 = Simplify<{} & {c: 1}[]>; // This works as expected
//   ^? type T1 = {c: 1}[]

type T2 = Simplify<Pick<{}, never> & {c: 1}[]>; // This unwraps the array
//   ^? type T2 = {[x: number]: {c: 1}; length:...

Pick<{}, never> evaluates down to {}, but the outcome is different from when it's a literal {}. This also means my workaround doesn't actually need an unknown, it works even with a literal {}.

som-sm · 2024-12-30T06:50:25Z

Also, simplified down the following conditional:

{[K in keyof Type as K extends (KeyPaths | StringToNumber<KeyPaths & string>) ? K : never]-?: Type[K]} extends infer RequiredPart
	? keyof RequiredPart extends never ? unknown : RequiredPart
	: never

to this:

BaseType extends UnknownArray
	? {}
	: {[K in keyof BaseType as K extends (KeyPaths | StringToNumber<KeyPaths & string>) ? K : never]-?: BaseType[K]}

I think this is much cleaner, refer this commit.

NOTE:
None of the solutions discussed so far work when the requirement is to remove an optional modifier from a tuple, like:

type T = SetRequiredDeep<{a: [string?]}, "a.0"> // doesn't remove the `?` modifier
//  actual: {a: [string?]} // returns the same thing
//  expected: {a: [string]}

And, it would need more thought in cases like these:

type T = SetRequiredDeep<{a: [string?, string?]}, "a.1"> // can't make `1` required, w/o making `0` required

But, I guess this shouldn't be a blocker.

som-sm · 2024-12-30T06:51:50Z

What are the next steps for this PR?

@hugomartinet PR LGTM!

@sindresorhus Shall we merge?

Beraliv · 2024-12-30T09:09:56Z

@som-sm great, this looks even simpler now!

sindresorhus · 2024-12-30T11:05:25Z

None of the solutions discussed so far work when the requirement is to remove an optional modifier from a tuple, like:

type T = SetRequiredDeep<{a: [string?]}, "a.0"> // doesn't remove the ? modifier
// actual: {a: [string?]} // returns the same thing
// expected: {a: [string]}
And, it would need more thought in cases like these:

type T = SetRequiredDeep<{a: [string?, string?]}, "a.1"> // can't make 1 required, w/o making 0 required

It would be great if you could open an issue about this.

sindresorhus · 2024-12-30T11:06:16Z

Looks good. Nice work, everyone 🙏

sindresorhus reviewed Aug 12, 2024

View reviewed changes

source/set-required-deep.d.ts Outdated Show resolved Hide resolved

sindresorhus requested a review from Emiyaaaaa August 12, 2024 23:41

Emiyaaaaa requested changes Aug 19, 2024

View reviewed changes

source/set-required-deep.d.ts Show resolved Hide resolved

test-d/set-required-deep.ts Outdated Show resolved Hide resolved

hugomartinet requested a review from Emiyaaaaa August 19, 2024 07:12

Emiyaaaaa requested changes Aug 19, 2024

View reviewed changes

test-d/set-required-deep.ts Show resolved Hide resolved

test-d/set-required-deep.ts Show resolved Hide resolved

source/set-required-deep.d.ts Outdated Show resolved Hide resolved

hugomartinet force-pushed the feat/SetRequiredDeep branch 2 times, most recently from 1c4f238 to e3c2874 Compare August 20, 2024 09:01

hugomartinet requested a review from Emiyaaaaa August 20, 2024 09:03

Beraliv reviewed Aug 22, 2024

View reviewed changes

test-d/set-required-deep.ts Outdated Show resolved Hide resolved

Beraliv reviewed Aug 22, 2024

View reviewed changes

source/set-required-deep.d.ts Show resolved Hide resolved

hugomartinet force-pushed the feat/SetRequiredDeep branch from e3c2874 to 40ad558 Compare October 25, 2024 14:38

hugomartinet requested review from sindresorhus and Beraliv October 25, 2024 14:39

sindresorhus approved these changes Oct 29, 2024

View reviewed changes

sindresorhus requested review from Beraliv and removed request for Beraliv October 29, 2024 09:18

Beraliv reviewed Oct 30, 2024

View reviewed changes

source/set-required-deep.d.ts Outdated Show resolved Hide resolved

Beraliv reviewed Oct 30, 2024

View reviewed changes

hugomartinet requested a review from Beraliv October 31, 2024 08:26

feat: Add SetRequiredDeep type

51ec78e

hugomartinet force-pushed the feat/SetRequiredDeep branch from d76a9ca to 51ec78e Compare November 28, 2024 19:13

som-sm reviewed Dec 14, 2024

View reviewed changes

fixup! feat: Add SetRequiredDeep type

83c9385

hugomartinet requested a review from som-sm December 27, 2024 21:40

sindresorhus added 2 commits December 29, 2024 13:01

Update set-required-deep.d.ts

0708275

Update set-required-deep.ts

12ffa36

sindresorhus approved these changes Dec 29, 2024

View reviewed changes

som-sm added 2 commits December 29, 2024 22:27

Merge branch 'main' into feat/SetRequiredDeep

4ccc8a8

refactor: simplify implementation of set-required-deep

21a8fad

som-sm approved these changes Dec 29, 2024

View reviewed changes

Beraliv approved these changes Dec 29, 2024

View reviewed changes

refactor: simplify required part conditional

a938634

Update set-required-deep.d.ts

64d5753

sindresorhus merged commit 3d54627 into sindresorhus:main Dec 30, 2024
12 checks passed

som-sm mentioned this pull request Dec 31, 2024

SetRequiredDeep doesn't remove optional modifiers from tuples #1026

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add `SetRequiredDeep` type #939

Add `SetRequiredDeep` type #939

hugomartinet commented Aug 12, 2024 •

edited

Loading

Emiyaaaaa commented Aug 14, 2024 •

edited

Loading

sindresorhus commented Aug 17, 2024

Emiyaaaaa commented Aug 21, 2024

hugomartinet commented Aug 21, 2024

Beraliv commented Oct 29, 2024

Beraliv Oct 30, 2024 •

edited

Loading

hugomartinet Oct 31, 2024

Beraliv Oct 30, 2024 •

edited

Loading

Beraliv commented Oct 30, 2024 •

edited

Loading

hugomartinet commented Nov 28, 2024

hugomartinet commented Dec 13, 2024

Beraliv commented Dec 13, 2024

som-sm left a comment

Beraliv commented Dec 26, 2024

hugomartinet commented Dec 27, 2024

som-sm commented Dec 29, 2024 •

edited

Loading

hugomartinet commented Dec 29, 2024

som-sm commented Dec 29, 2024 •

edited

Loading

hugomartinet commented Dec 29, 2024

Beraliv commented Dec 29, 2024

Beraliv commented Dec 29, 2024

Beraliv commented Dec 29, 2024 •

edited

Loading

Beraliv left a comment •

edited

Loading

som-sm commented Dec 30, 2024

som-sm commented Dec 30, 2024 •

edited

Loading

som-sm commented Dec 30, 2024

Beraliv commented Dec 30, 2024

sindresorhus commented Dec 30, 2024

sindresorhus commented Dec 30, 2024

Add SetRequiredDeep type #939

Add SetRequiredDeep type #939

Conversation

hugomartinet commented Aug 12, 2024 • edited Loading

Emiyaaaaa commented Aug 14, 2024 • edited Loading

sindresorhus commented Aug 17, 2024

Emiyaaaaa commented Aug 21, 2024

hugomartinet commented Aug 21, 2024

Beraliv commented Oct 29, 2024

Beraliv Oct 30, 2024 • edited Loading

Choose a reason for hiding this comment

hugomartinet Oct 31, 2024

Choose a reason for hiding this comment

Beraliv Oct 30, 2024 • edited Loading

Choose a reason for hiding this comment

Beraliv commented Oct 30, 2024 • edited Loading

hugomartinet commented Nov 28, 2024

hugomartinet commented Dec 13, 2024

Beraliv commented Dec 13, 2024

som-sm left a comment

Choose a reason for hiding this comment

Beraliv commented Dec 26, 2024

hugomartinet commented Dec 27, 2024

som-sm commented Dec 29, 2024 • edited Loading

hugomartinet commented Dec 29, 2024

som-sm commented Dec 29, 2024 • edited Loading

hugomartinet commented Dec 29, 2024

Beraliv commented Dec 29, 2024

Beraliv commented Dec 29, 2024

Beraliv commented Dec 29, 2024 • edited Loading

Beraliv left a comment • edited Loading

Choose a reason for hiding this comment

som-sm commented Dec 30, 2024

som-sm commented Dec 30, 2024 • edited Loading

som-sm commented Dec 30, 2024

Beraliv commented Dec 30, 2024

sindresorhus commented Dec 30, 2024

sindresorhus commented Dec 30, 2024

Add `SetRequiredDeep` type #939

Add `SetRequiredDeep` type #939

hugomartinet commented Aug 12, 2024 •

edited

Loading

Emiyaaaaa commented Aug 14, 2024 •

edited

Loading

Beraliv Oct 30, 2024 •

edited

Loading

Beraliv Oct 30, 2024 •

edited

Loading

Beraliv commented Oct 30, 2024 •

edited

Loading

som-sm commented Dec 29, 2024 •

edited

Loading

som-sm commented Dec 29, 2024 •

edited

Loading

Beraliv commented Dec 29, 2024 •

edited

Loading

Beraliv left a comment •

edited

Loading

som-sm commented Dec 30, 2024 •

edited

Loading