Add SetRequiredDeep type

[hugomartinet]

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
//  }[]
// }

[Emiyaaaaa]

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

@sindresorhus how about you think?

[sindresorhus]

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.

[Emiyaaaaa]

Need to resolve all conversation

[hugomartinet]

Need to resolve all conversation

Done

[Beraliv]

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

[Beraliv]

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

[hugomartinet]

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]

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]

@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]

@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]

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

[Beraliv]

@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:

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

   Shouldn't make b optional.
   
   

2.  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.
   
   

3.  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.
   
   

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

   Doesn't work with number keys.