Add recurseIntoArrays option for PartialDeep

[bbrk24]

Closes #367

This PR adds the {recurseIntoArrays: false} option as discussed in that issue. The property is optional (i.e. you may pass {} for the options) for forwards-compatibility: should there be more options in the future, such as recurseIntoSets, you may specify any one and not the rest.

[Nokel81]

This change does not seem to be backwards compatible even though it was released in a minor version.

[sindresorhus]

@Nokel81 You need to be more specific. What exactly is it breaking?

[Nokel81]

We have the following type:

enum KubeObjectScope {
    Namespace = 0,
    Cluster = 1
}

interface BaseKubeJsonApiObjectMetadata<Namespaced extends KubeObjectScope> {
    annotations?: Partial<Record<string, string>>;
    clusterName?: string;
    readonly creationTimestamp?: string;
    readonly deletionGracePeriodSeconds?: number;
    readonly deletionTimestamp?: string;
    generateName?: string;
    readonly generation?: number;
    labels?: Partial<Record<string, string>>;
    managedFields?: unknown[];
    readonly name: string;
    readonly namespace?: ScopedNamespace<Namespaced>;
    readonly resourceVersion?: string;
    readonly selfLink?: string;
    readonly uid?: string;
    [key: string]: unknown;
}

type KubeJsonApiObjectMetadata<Namespaced extends KubeObjectScope = KubeObjectScope> = BaseKubeJsonApiObjectMetadata<Namespaced> & (Namespaced extends KubeObjectScope.Namespace ? {
    readonly namespace: string;
} : {});

type KubeObjectMetadata<Namespaced extends KubeObjectScope = KubeObjectScope> = KubeJsonApiObjectMetadata<Namespaced> & {
    readonly selfLink: string;
    readonly uid: string;
    readonly name: string;
    readonly resourceVersion: string;
};

// This is the important type
class KubeObject<Metadata extends KubeObjectMetadata<KubeObjectScope> = KubeObjectMetadata<KubeObjectScope>, Status = unknown, Spec = unknown>  {}

And we upgraded to version 2.17.0 but a consumer of our public API is still on 2.12.1 of type-fest.

In our code we have something like the following:

function createObject<T extends KubeObject>(name: string, descriptor: PartialDeep<T>): Promise<T>;

And our consumer wraps that call with there own generic function of the same signature. But there is now the following type error:

Argument of type 'PartialDeep<T>' is not assignable to parameter of type 'PartialDeep<T, {}> | undefined'.
  Type 'T | (T extends Map<infer KeyType, infer ValueType> ? PartialMapDeep<KeyType, ValueType> : T extends Set<infer ItemType> ? PartialSetDeep<...> : T extends ReadonlyMap<...> ? PartialReadonlyMapDeep<...> : T extends ReadonlySet<...> ? PartialReadonlySetDeep<...> : T extends (...arguments: any[]) => unknown ? T | undefi...' is not assignable to type 'PartialDeep<T, {}> | undefined'.
    Type 'BuiltIns & T' is not assignable to type 'PartialDeep<T, {}> | undefined'.
      Type 'string & T' is not assignable to type 'PartialDeep<T, {}> | undefined'.
        Type 'string & T' is not assignable to type 'PartialDeep<T, {}>'.
          Type 'PartialObjectDeep<KubeObject<KubeObjectMetadata<KubeObjectScope>, unknown, unknown>>' is not assignable to type 'PartialDeep<T, {}>'.ts(2345)

[sindresorhus]

@bbrk24 Can you look into this ^

[bbrk24]

@Nokel81 I'm unable to reproduce this in the playground, based on what information you've provided me. Could you provide either a playground link or a repo with a MRE so I can investigate this?

[Nokel81]

Sure, here is a link to a playground

[bbrk24]

Oh I see, this only occurs when you have two different versions of type-fest present at the same time. I think that can cause errors even from a patch-level change: as an obvious example, say a type mistakenly produces string where number is expected; changing the behavior to correctly give number is semver-patch, but loading the pre-patch and post-patch versions at the same time will cause a type mismatch. So, I'm not sure we should even support this use case.

[Nokel81]

I am not quite sure that I agree that is a semver-patch change in the strictest sense because we are dealing with a type level library here.

From the definition of semver-patch and semver-minor, both are supposed to be resilient to multiple versions, I thought.

[bbrk24]

From the definition of semver-patch and semver-minor, both are supposed to be resilient to multiple versions, I thought.

That's in reference to upgrading. If you have a codebase that works with 1.2.3, it should still work with 1.2.4. I don't believe the standard says anything about having different parts of the project use both at the same time.