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!