0.26.2

Updates:

• 331 Revert 0.25.0 Intersect logic for Composite

Notes:

This PR reverts the logic on Type.Composite back to 0.25.0 Type.Intersect due to excessive type instantiation issues. On 0.26.0, Type.Composite attempted to take a union for overlapping properties, however due to the sophistication required to type map the unions for overlapping properties, this has resulted in type instantiation problems for some users upgrading to 0.26.0.

As such, 0.26.2 reverts back to the 0.25.0 interpretation, but applies type mappings more inline with TS's interpretation of an overlapping varying property types. In the examples below, the type C is the evaluated type for Type.Composite. Note that TS will not union for overlapping properties and instead evaluate never. The 0.26.2 implementation falls inline with this evaluation.

{ // evaluation case 1: non-varying
  type T = { a: number } & { a: number }

  type C = {[K in keyof T]: T[K] }  // type C = { a: number }
}

{ // evaluation case 2: varying
  type T = { a: number } & { a: string }

  type C = {[K in keyof T]: T[K] }  // type C = { a: never }
}

{ // evaluation case 3: single optional
  type T = { a?: number } & { a: number }

  type C = {[K in keyof T]: T[K] }  // type C = { a: number }
}

{ // evaluation case 4: all optional
  type T = { a?: number } & { a?: number }

  type C = {[K in keyof T]: T[K] }  // type C = { a?: number | undefined }
}

Note: the Type.Composite is intended to be a temporary type which can be replaced with a more general Type.Mapped in future revisions of TypeBox. As the infrastructure to support mapped types does not exist, users can use Type.Composite to partially replicate mapped type evaluation for composited object types only.