Type manipulations: union to tuple

[krryan]

A suggestion to create a runtime array of union members was deemed out of scope because it would not leave the type system fully erasable (and because it wouldn't be runtime complete, though that wasn't desired). This suggestion is basically a variant of that one that stays entirely within the type domain, and thus stays erasable.

The suggestion is for a keyword similar to keyof that, when given a union type, would result in a tuple type that includes each possibility in the union.

Combined with the suggestion in this comment to instead implement a codefix to create the array literal, this could be used to ensure that 1. the array was created correctly to begin with, and 2. that any changes to the union cause an error requiring the literal array to be updated. This allows creating test cases that cover every possibility for a union.

Syntax might be like this:

type SomeUnion = Foo | Bar;

type TupleOfSomeUnion = tupleof SomeUnion; // has type [Foo, Bar]

type NestedUnion = SomeUnion | string;

type TupleOfNestedUnion = tupleof NestedUnion; // has type [Foo, Bar, string]

Some issues I foresee:

1. I don't know what ordering is best (or even feasible), but it would have to be nailed down in some predictable form.

2. Nesting is complicated.

3. I expect generics would be difficult to support?

4. Inner unions would have to be left alone, which is somewhat awkward. That is, it would not be reasonable to turn Wrapper<Foo|Bar> into [Wrapper<Foo>, Wrapper<Bar>] even though that might (sometimes?) be desirable. In some cases, it’s possible to use conditional types to produce that distribution, though it has to be tailored to the particular Wrapper. Some way of converting back and forth between Wrapper<Foo|Bar> and Wrapper<Foo>|Wrapper<Bar> would be nice but beyond the scope of this suggestion (and would probably require higher-order types to be a thing).

5. My naming suggestions are weak, particularly tupleof.

NOTE: This suggestion originally also included having a way of converting a tuple to a union. That suggestion has been removed since there are now ample ways to accomplish that. My preference is with conditional types and infer, e.g. ElementOf<A extends unknown[]> = A extends (infer T)[] ? T : never;.

[zpdDG4gta8XKpMCd]

functionof would not hurt either: #12265

[aleclarson]

You can already do tuple -> union conversion:

[3, 1, 2][number] // => 1 | 2 | 3

type U<T extends any[], U = never> = T[number] | U
U<[3, 1, 2]> // => 1 | 2 | 3
U<[1], 2 | 3> // => 1 | 2 | 3

How about a concat operator for union -> tuple conversion?

type U = 1 | 2 | 3
type T = [0] + U        // => [0, 1, 2, 3]
type S = U + [0]        // => [1, 2, 3, 0]
type R = [1] + [2]      // => [1, 2]
type Q = R + R          // => [1, 2, 1, 2]
type P = U + U          // Error: cannot use concat operator without >=1 tuple
type O = [] + U + U     // => [1, 2, 3, 1, 2, 3]
type N = [0] + any[]    // => any[]
type M = [0] + string[] // Error: type '0' is not compatible with 'string'
type L = 'a' + 16 + 'z' // => 'a16z'

Are there good use cases for preserving union order? (while still treating unions as sets for comparison purposes)

[krryan]

I had used a conditional type for tuple to union:

type ElementOf<T> = T extends (infer E)[] ? E : T;

Works for both arrays and tuples.

[ShanonJackson]

or just [1,2,3][number] will give you 1 | 2 | 3

[ShanonJackson]

Decided to stop being a lurker and start joining in the Typescript community alittle more hopefully this contribution helps put this Union -> Tuple problem to rest untill Typescript hopefully gives us some syntax sugar.

This is my "N" depth Union -> Tuple Converter that maintains the order of the Union

// add an element to the end of a tuple
type Push<L extends any[], T> =
  ((r: any, ...x: L) => void) extends ((...x: infer L2) => void) ?
    { [K in keyof L2]-?: K extends keyof L ? L[K] : T } : never
  
export type Prepend<Tuple extends any[], Addend> = ((_: Addend, ..._1: Tuple) => any) extends ((
	..._: infer Result
) => any)
	? Result
	: never;
//
export type Reverse<Tuple extends any[], Prefix extends any[] = []> = {
	0: Prefix;
	1: ((..._: Tuple) => any) extends ((_: infer First, ..._1: infer Next) => any)
		? Reverse<Next, Prepend<Prefix, First>>
		: never;
}[Tuple extends [any, ...any[]] ? 1 : 0];



// convert a union to an intersection: X | Y | Z ==> X & Y & Z
type UnionToIntersection<U> =
  (U extends any ? (k: U) => void : never) extends ((k: infer I) => void) ? I : never

// convert a union to an overloaded function X | Y ==> ((x: X)=>void) & ((y:Y)=>void)     
type UnionToOvlds<U> = UnionToIntersection<U extends any ? (f: U) => void : never>;

// returns true if the type is a union otherwise false
type IsUnion<T> = [T] extends [UnionToIntersection<T>] ? false : true;

// takes last from union
type PopUnion<U> = UnionToOvlds<U> extends ((a: infer A) => void) ? A : never;

// takes random key from object
type PluckFirst<T extends object> = PopUnion<keyof T> extends infer SELF ? SELF extends keyof T ? T[SELF] : never;
type ObjectTuple<T, RES extends any[]> = IsUnion<keyof T> extends true ? {
    [K in keyof T]: ObjectTuple<Record<Exclude<keyof T, K>, never>, Push<RES, K>> extends any[]
        ? ObjectTuple<Record<Exclude<keyof T, K>, never>, Push<RES, K>>
        : PluckFirst<ObjectTuple<Record<Exclude<keyof T, K>, never>, Push<RES, K>>>
} : Push<RES, keyof T>;

/** END IMPLEMENTATION  */



type TupleOf<T extends string> = Reverse<PluckFirst<ObjectTuple<Record<T, never>, []>>>

interface Person {
    firstName: string;
    lastName: string;
    dob: Date;
    hasCats: false;
}
type Test = TupleOf<keyof Person> // ["firstName", "lastName", "dob", "hasCats"]

[krryan]

Finally removed the bit about union to tuple, since there are plenty of ways to do that now (there weren’t when this suggestion was first made). Also, much thanks to @ShanonJackson, that looks awesome and I will have to try that. Still, that’s a lot of code for this; sugar would be rather appreciated here. Or at least a built-in type that comes with Typescript, so that doesn’t have to be re-implemented in every project.

[aleclarson]

@krryan A solution of that size should be published as an NPM package, IMO.

Worth noting: The TupleOf type provided by @ShanonJackson only supports string unions, so it's not a universal solution by any means.

[krryan]

@aleclarson Yes, but installing a dependency is, to my mind, still “reimplementing” it, at least in the context here. Sure, an NPM package is superior to copying and pasting that code around. But I don’t think either should be necessary for this. It’s a language construct that is broadly useful to all Typescript developers, in my opinion, so it should just be available (and quite possibly be implemented more easily within tsc than as a type in a library).

Anyway, good point about the string limitation; that’s quite severe (I might still be able to use that but it’s going to take some work since I’ll have to get a tuple of my discriminants and then distribute those appropriately, but I think it will work for my purposes).

[dragomirtitian]

@ShanonJackson

I fear that while this solution works, it is very compiler unfriendly .. I added just a couple more keys to the object and when I hovered over it the language server got up to 100% CPU usage, ate up 3GB of RAM and no tooltips ever show up.

interface Person {
    firstName: string;
    lastName: string;
    dob: Date;
    hasCats: false;
    hasCats1: false;
    hasCats2: false;
    hasCats3: false;
    hasCats4: false;
}
type Test = TupleOf<keyof Person> //  tool tip never shows up HUGE amount of RAM and CPU Used,

[RyanCavanaugh]

Sorry this has been stuck in Need Investigation so long!

My primary question is: What would this be useful for? Hearing about use cases is really important; the suggestion as it stands seems like an XY problem situation.

Secondary comments: This suggestion could almost certainly never happen; problems with it are many.

First, union order is not something we can ever allow to be observable. Internally, unions are stored as a sorted list of types (this is the only efficient way to quickly determine relationships between them), and the sort key is an internal ID that's generated incrementally. The practical upshot of this is that two extremely similar programs can generate vastly different union orderings, and the same union observed in a language service context might have a different ordering than when observed in a commandline context, because the order in which types are created is simply the order in which they are checked.

Second, there are basic identities which are very confusing to reason about. Is tupleof T | ( U | V ) [T, U | V] or [T, U, V] ? What about this?

// K always has arity 2?
type K<T, U> = tupleof (T | U);
// Or Q has arity 3? Eh?
type Q = K<string, number | boolean>;

There are more problems but the first is immediately fatal IMO.

[krryan]

@RyanCavanaugh The primary use-case for me is to ensure complete coverage of all the types that a function claims to be able to handle in testing scenarios. There is no way to generate an array you can be sure (tsc will check) has every option.

Order doesn’t matter to me at all, which makes it frustrating to have that as a fatal flaw. I think Typescript programmers are already familiar with union ordering being non-deterministic, and that’s never really been a problem. I wonder if creating something typed as Set<MyUnion> but with a fixed size (i.e. equal to the number of members of MyUnion) would be more valid? Sets are ordered, but that would be at runtime, rather than exposed as part of its type, which maybe makes it acceptable (since it’s not part of the type, looking at the code you have no reason to expect any particular order).

As for T | ( U | V ) I would definitely want that to be [T, U, V]. On K and Q, those results (arity 2, arity 3) don’t seem surprising to me and seem quite acceptable. I’m maybe not seeing the issue you’re getting at?

[dragomirtitian]

@krryan Yes but the problem is that if 'A' | 'B' gets transformed to ['A', 'B'] it should always be transformed to ['A', 'B']. Otherwise you will get random errors at invocation site. I think the point @RyanCavanaugh is making is that this order cannot be guaranteed 100% of the time and may depend on the order and the sort key which is "... an internal ID that generated incrementally"

type  A = "A"
type  B = "B"

type AB = A | B
function tuple(t: tupleof AB) {}

tuple(['A', 'B'])// Change the order in which A and B are declared and this becomes invalid .. very brittle ...

[ShanonJackson]

Yes tuples have a strict order unless you write a implementation that can turn [A, B] into [A, B] | [B, A] (permutations). However such a type-level implementation would also be very heavy on the compiler without syntax sugar as when you get up to 9! you get into some ridiculous amount of computation that a recursive strategy will struggle.

If people do care about the order (i don't) then i think just write a implementation that turns [A, B] into...
[A | B, A | B] intersected with a type that makes sure both A & B are present? therefore you can't go [A, A] and also can't go [A, A, B] but can go [A, B] or [B, A]

[krryan]

@dragomirtitian I fully understand that, which is why I suggested some alternative type that isn’t a tuple type to indicate that we are talking about an unordered set of exactly one each of every member of a union.

Which it now dawns on me can be accomplished for strings by creating a type that uses every string in a union of strings as the properties of a type. For example:

const tuple = <T extends unknown[]>(...a: T): T => a;

type ElementOf<T> = T extends Array<infer E> ? E : T extends ReadonlyArray<infer E> ? E : never;
type AreIdentical<A, B> = [A, B] extends [B, A] ? true : false;

type ObjectWithEveryMemberAsKeys<U extends string> = {
    [K in U]: true;
};

const assertTupleContainsEvery = <Union extends string>() =>
    <Tuple extends string[]>(
        tuple: Tuple,
    ) =>
        tuple as AreIdentical<
            ObjectWithEveryMemberAsKeys<Union>,
            ObjectWithEveryMemberAsKeys<ElementOf<Tuple>>
        > extends true ? Tuple : never;

const foo = 'foo' as const;
const bar = 'bar' as const;
const baz = 'baz' as const;
const assertContainsFooBar = assertTupleContainsEvery<typeof foo | typeof bar>();
const testFooBar = assertContainsFooBar(tuple(foo, bar)); // correctly ['foo', 'bar']
const testBarFoo = assertContainsFooBar(tuple(bar, foo)); // correctly ['bar', 'foo']
const testFoo = assertContainsFooBar(tuple(foo)); // correctly never
const testFooBarBaz = assertContainsFooBar(tuple(foo, bar, baz)); // correctly never
const testFooBarBar = assertContainsFooBar(tuple(foo, bar, bar)); // incorrectly ['foo', 'bar', 'bar']; should be never

There’s probably a way to fix the foo, bar, bar case, and in any event that’s the most minor failure mode. Another obvious improvement is to change never to something that would hint at what’s missing/extra, for example

        > extends true ? Tuple : {
            missing: Exclude<Union, ElementOf<Tuple>>;
            extra: Exclude<ElementOf<Tuple>, Union>;
        };

though that potentially has the problem of a user thinking it’s not an error report but actually what the function returns, and trying to use .missing or .extra (consider this another plug for #23689).

This works for strings (and does not have the compiler problems that the suggestion by @ShanonJackson has), but doesn’t help non-string unions. Also, for that matter, my real-life use-case rather than Foo, Bar, Baz is getting string for ElementOf<Tuple> even though on hover the generic inferred for Tuple is in fact the tuple and not string[], which makes me wonder if TS is shorting out after some number of strings and just calling it a day with string.

[RyanCavanaugh]

The primary use-case for me is to ensure complete coverage of all the types that a function claims to be able to handle in testing scenarios

How do tuples, as opposed to unions, help with this? I'm begging y'all, someone please provide a hypothetical code sample here for what you'd do with this feature so I can understand why 36 people upvoted it 😅

Order doesn’t matter to me

I can accept this at face value, but you have to recognize that it'd be a never-ending source of "bug" reports like this. The feature just looks broken out of the gate:

type NS = tupleof number | string;
// Bug: This is *randomly* accepted or an error, depending on factors which
// can't even be explained without attaching a debugger to tsc
const n: NS = [10, ""];

I question whether it's even a tuple per se if you're not intending to test assignability to/from some array literal.

[KiaraGrouwstra]

@RyanCavanaugh:

Is tupleof T | ( U | V ) [T, U | V] or [T, U, V] ?

I'm with @krryan -- only the latter makes sense here. The former would seem quite arbitrary.

union order is not something we can ever allow to be observable.

This is perfectly, as this is not a blocker to its use-cases.

My primary question is: What would this be useful for? Hearing about use cases is really important; the suggestion as it stands seems like an XY problem situation.

One big problem I see this as solving is map functions on objects (Lodash's mapValues, Ramda's map), which this would allow accurately typing even for heterogeneous objects (-> calculating value types for each key), i.e. what's solved by Flow's $ObjMap, though this implies getting object type's keys, converting them to a union, then converting this union to a tuple type, then using type-level iteration through this tuple using recursive types so as to accumulate value types for each key.

TupleOf may let us do this today. I don't expect this to be a supported use-case of TypeScript. Going through this to type one function may sound silly. But I think it's kind of big.

Anyone who has used Angular's state management library ngrx will be aware that getting type-safe state management for their front-end application involves horrific amounts of boilerplate. And in plain JavaScript, it has always been easy to imagine an alternative that is DRY.

Type-safe map over heterogeneous objects addresses this for TypeScript, by allowing granular types to propagate without requiring massive amounts of boilerplate, as it lets you separate logic (functions) from content (well-typed objects).

edit: I think this depends on the boogieman $Call as well. 😐

[treybrisbane]

I basically just want to be able to do this:

const objFields: [['foo', 3], ['bar', true]] = entries({ foo: 3, bar: true });

I'm not sure whether the ES spec guarantees ordering of object entries or not. Node's implementation seems to, but if the spec doesn't, then this may just not be something TypeScript should facilitate (since it would be assuming a specific runtime).

[RyanCavanaugh]

@treybrisbane the order is not guaranteed.

What do you think of this?

type Entries<K extends object> = {
    [Key in keyof K]: [Key, K[Key]]
};
function entries<K extends object>(obj: K): Entries<K>[keyof K][] {
    return Object.keys(obj).map(k => [k, obj[k]]) as any;
}

const objFields = entries({ foo: 3, bar: "x" });
for (const f of objFields) {
    if (f[0] === "foo") {
        console.log(f[1].toFixed());
    } else if (f[0] === "bar") {
        console.log(f[1].toLowerCase());
    } else {
        // Only typechecks if f[0] is exhausted
        const n: never = f[1]
    }
}

[zpdDG4gta8XKpMCd]

@RyanCavanaugh when you say things about how order matters it makes me smile, please tell me where in the spec of typescript can i read about the order of overloads on the same method of the same interface coming from different *.d.ts files please, thank you

[RyanCavanaugh]

Each overload is in the order that it appears in each declaration, but the ordering of the declarations is backwards of the source file order. That's it.

[zpdDG4gta8XKpMCd]

and source file order is what? 🎥🍿😎

[RyanCavanaugh]

Quite the tangent from this thread!

[zpdDG4gta8XKpMCd]

you people did it one time, you can do it again, order is order

[jasonkuhrt]

@tatemz with that I get this error:

TS 4.4.2

[jhunterkohler]

@jasonkuhrt This is likely a problem inherent in TypeScript due to the size of your union. It has a limit on the depth of recursive calculation. With @tatemz 's solution, 4.5 is allowing me something like 47 long string properties while only ~35 in 4.4. It's odd, but so is Typescript 😆

[tatemz]

Documenting some findings. I originally found this thread because I was interested in taking a Union (e.g. "foo" | "bar") and then map it to some new type. Additionally, I found this thread when I needed to build out n permutations of a union.

That said, it turns out most of my use-cases can be solved by this answer by using a distributive conditional type.

Example (playground link)

type MyLiterals = "foo" | "bar";

type MyLiteralsMappedToObjects<T extends MyLiterals> = T extends never ? never : { value: MyLiteral };

[fdcds]

If you find yourself here wishing you had this operation, PLEASE EXPLAIN WHY WITH EXAMPLES, we will help you do something that actually works instead.

I would like to find a solution for the following:

type MyProps = {
  booleanProp: boolean;
  optionalDateProp?: Date;
};

const myJSONObject = {
  "booleanProp": "false",
  "optionalDateProp": "2021-11-25T12:00:00Z"
};

const coerce = (o: any): MyProps => /* ??? */
coerce(myJSONObject) /* = {
  booleanProp: false,
  optionalDateProp: new Date("2021-11-25T12:00:00Z")
} */

I wish for this operation, so I can implement coerce like this:

// https://stackoverflow.com/a/66144780/11630268
type KeysWithValsOfType<T, V> = keyof {
  [P in keyof T as T[P] extends V ? P : never]: P;
} &
  keyof T;

type MyPropsOfTypeDate = KeysWithValsOfType<MyProps, Date> | KeysWithValsOfType<MyProps, Date | unknown>;
const myPropsOfTypeDate = new Set(/* ??? */);
type MyPropsOfTypeBoolean = KeysWithValsOfType<MyProps, boolean> | KeysWithValsOfType<MyProps, boolean | unknown>;
const myPropsOfTypeBoolean = new Set(/* ??? */);

type MyPropKeys = keyof MyProps;
const myPropKeys = new Set(/* ??? */);

const coerce = (o: any): MyProps => {
  let p = {};
  for (const k in myProps) {
    if (myPropsOfTypeDate.has(k)) {
      p[k] = new Date(o[k]);
    } else if (myPropsOfTypeBoolean.has(k)) {
      p[k] = o[k] === "true";
    } else {
      p[k] = o[k]
    }
  }
  return p;
}

How can I achieve this (or something comparable) without turning a union type of string literals into a runtime object (Set, array, ...) like suggested in this issue?

[krryan]

@fdcds The typing of your coerce function calls for a mapped type with some conditional typing inside, and the runtime will need some standard JavaScript approaches to detecting Date objects. You definitely do not need the functionality requested here; even if we had it, there are better ways to do what you want.

This isn’t really the place to get into those better ways, but were it me, I would go with this:

type MyJsonObject = {
  [K in keyof MyProps]: MyProps[K] extends Date ? string : MyProps[K];
}

function coerce(props: MyProps): MyJsonObject {
  result = {} as MyJsonObject;
  Object.keys(props).forEach(key => {
    result[key] = props[key] instanceof Date ? props[key].toISOString() : props[key];
  });
  return result;
}

I just woke up, wrote this on my phone, and did not test it. If it doesn’t completely work, it should still be enough to point you in the right directions. Please do not clutter this thread, or even this issue tracker, with questions about it: questions like this belong on Stack Overflow.

[Dragon-Hatcher]

Here is how you can extend @tatemz solution to work for much larger unions by taking advantage of the fact that typescript uses tail-call for certain types of recursive types. This should work for unions of size up to 1000. (Though it gets slow fast.)

type UnionToIntersection<U> = (
  U extends never ? never : (arg: U) => never
) extends (arg: infer I) => void
  ? I
  : never;

type UnionToTuple<T, A extends any[] = []> = UnionToIntersection<
  T extends never ? never : (t: T) => T
> extends (_: never) => infer W
  ? UnionToTuple<Exclude<T, W>, [...A, W]>
  : A;

[donaldpipowitch]

I would like to map a union to a tuple and then use this tuple to map it to an array where every original union type is used once as a key. Is that possible somehow? I tried this, but it fails:

type SomeUnion = 'hello' | 'world';

type SomeTuple = UnionToTuple<SomeUnion>;

type Box<T> = { someField: string; type: T };

type Boxes = {
    [Index in keyof SomeTuple]: Box<SomeTuple[Index]>
} & {length: SomeTuple['length']};

const boxes: Boxes = [
    { someField: '', type: 'hello' },
    { someField: '', type: 'world' },
]


// helper below:
// see https://github.com/microsoft/TypeScript/issues/13298#issuecomment-1610361208
type UnionToIntersection<U> = (U extends never ? never : (arg: U) => never) extends (arg: infer I) => void
  ? I
  : never;
type UnionToTuple<T, A extends any[] = []> = UnionToIntersection<T extends never ? never : (t: T) => T> extends (_: never) => infer W
  ? UnionToTuple<Exclude<T, W>, [...A, W]>
  : A;

link

[krryan]

I would like to map a union to a tuple and then use this tuple to map it to an array where every original union type is used once as a key. Is that possible somehow?

No, it is not, and basically can’t be made to be. Effectively, the problem is that unions do not have order, while arrays (and sets and so on) do. So to properly capture “each possibility of 'hello' | 'world' exactly once,” you need ['hello', 'world'] | ['world', 'hello']. For each additional option in the union, the number of tuples you have to consider grows exponentially.

If you are talking about a union of strings (or numbers, or symbols I think?), there is a solution: you can use an object’s keys as an “order-less” “array” of sorts. (In truth, object keys do have an order defined by JavaScript but Typescript treats reorderings as the same object.)

But for me, for the most part, I have tried to stick to defining the array first, and defining the union based on the array (which is easy). Kind of awkward, not my favorite, I just woke up so I can’t think of any but I feel like there are some limitations, but it mostly works.

[Cellule]

For those using asAllUnionTuple from @Harpush 's solution in TypeScript 5.1
I've noticed that it started breaking in places where the array wasn't const

Adding as const at the call site fixes the problem: asAllUnionTuple<U>()([...] as const)
But I've also figured that changing U in asAllUnionTuple has the same effect without having the change the call site

const asAllUnionTuple = <T>() => <const U extends ReadonlyArray<any>>(
  cc: AllUnionTuple<T, U>
) => cc;

The downside is that the resulting tuple is now readonly which can potentially cause other problems in your code

[rtritto]

type MyTypeUnion = MyType1 | MyType2[]

type UnionToTuple = ...

type ConvertedTuple = UnionToTuple<MyTypeUnion>

type FirstType = ConvertedTuple[1]  // MyType1
type SecondType = ConvertedTuple[2]  // MyType2[]

How can I do the UnionToTuple type definition?

[krryan]

How can I do the UnionToTuple type definition?

You can’t, it’s not possible, that’s why this issue is closed. Unions are unordered, tuples are ordered—a tuple requires information that a union hasn’t got. If possible—it isn’t always—you may want to write your definition as an array to begin with, and then tuple-to-union is easy:

export const tuple = [
  // …
] as const;
export type Union = typeof tuple[number];

Unfortunately, this often isn’t workable when your union isn’t hard-coded, but derived from other types.

There is a way you can have the compiler check that your tuple contains all the elements in the union, nothing else, and no duplicates, but it’s a fairly tedious amount of boilerplate:

This bit you can re-use:

/** The unique elements of the input tuple, in order. Only works with `readonly` tuples. */
export type SetTuple<T extends readonly any[]> = _SetTuple<T>;
type _SetTuple<T extends readonly any[], A extends readonly any[] = readonly []> =
    T extends readonly [infer H, ...infer R]
        ? H extends A[number]
            ? _SetTuple<R, A>
            : _SetTuple<R, readonly [...A, H]>
        : A;

Here are your union and tuple definitions, and compile-time testing that the tuples match the union.

import { SetTuple } from 'set-tuple'; // wherever SetTuple is exported from

export type TheUnion = 'foo' | 'bar';

/** A correct tuple, in the same order as the union */
export const validTuple = ['foo', 'bar'] as const;
((): SetTuple<typeof validTuple> => validTuple); // no error: has no duplicates
((): readonly TheUnion[] => validTuple); // no error: does not include anything but 'foo' and 'bar'
((union: TheUnion): typeof validTuple[number] => union); // no error: includes both 'foo' and 'bar'

/** A correct tuple, in the opposite order as the union (doesn't matter) */
export const alsoValidTuple = ['bar', 'foo'] as const;
((): SetTuple<typeof alsoValidTuple> => alsoValidTuple); // no error: has no duplicates
((): readonly TheUnion[] => alsoValidTuple); // no error: does not include anything but 'foo' and 'bar'
((union: TheUnion): typeof alsoValidTuple[number] => union); // no error: includes both 'foo' and 'bar'

/** A wrong tuple, for several reasons */
export const invalidTuple = ['bar', 'bar', 'baz'] as const;
((): SetTuple<typeof invalidTuple> => invalidTuple); // error: duplicate 'bar' elements
((): readonly TheUnion[] => invalidTuple); // error: 'baz' is not in the union
((union: TheUnion): typeof invalidTuple[number] => union); // error: 'foo' is not in the tuple

Here, we use a trio of never-invoked anonymous function expressions, which don’t pollute the namespace and have minimal effect on the run time, and allow us to include some statements that the compiler will check for us, so we can confirm the tuple is what we want it to be. As you can see, you have to include all three statements for each tuple you want to check. (You could combine the first two, technically, but that’s not a lot of savings and it makes the error messages harder to read.) I tried writing a utility type or even utility function that would save on this boilerplate, but everything I came up with had the same two flaws: you still needed a bunch of boilerplate to cause it to actually error when it’s supposed to, and the error messages are impossible to read.

Still, if you only have a few such tuples, and they really must cover the union, this is a safe solution.

[yuanhong88]

type TuplifyUnion<U extends string> = {
  [S in U]: // for each variant in the union
    Exclude<U, S> extends never // remove it and..
      ? [S] // ..stop recursion if it was the last variant
      : [...TuplifyUnion<Exclude<U, S>>, S] // ..recur if not
}[U] // extract all values from the object

type fs = TuplifyUnion<'1' | '2' | '3'>;
//equal to
type fs = ["3", "2", "1"] | ["2", "3", "1"] | ["3", "1", "2"] | ["1", "3", "2"] | ["2", "1", "3"] | ["1", "2", "3"]

playground

[krryan]

Ok, yes, that works, as long as the union is very small. I tested my implementation with a 114-member union (letters A-Z and a-z, digits 0-9, Greek letters Α-Ω and α-ω, and 'foo', 'bar', and 'baz'), which was no problem. In my testing, TuplifyUnion starts to slow down at 9 union members, and at 10 evaluating it in VS Code Intellisense times out and it’s typed as any (and I’m frankly impressed as hell that Typescript got that far, since the resulting type for 9 was a union of over 300,000 tuples). TuplifyUnion also had significant performance problems that affected my entire editor with larger unions.

I also came up with a less-boilerplate-y way to create a re-usable type to check a tuple covers a union:

export type TestTupleExactlyCoversUnion<T extends readonly any[], U extends string | number | bigint | boolean | null | undefined> =
    [T, U] extends [SetTuple<T> & readonly U[], T[number]] ? true : Split<T extends any ? 'string--------------------------------------------' : never>;
type Split<T> = T extends `${infer H}${infer Rest}` ? readonly [H, ...Split<Rest>] : readonly [];

{
    type Good = TestTupleExactlyCoversUnion<typeof validTuple, TheUnion>;
    type Bad = TestTupleExactlyCoversUnion<typeof invalidTuple, TheUnion>;
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
               Type instantiation is excessively deep and possibly infinite. ts(2589)

}

Putting the types in the brackets avoids polluting the namespace, so the names only have to be unique within that context, which is good. You still have to assign names to them, which is annoying. The error message is also much less useful: you just get “Type instantiation is excessively deep and possibly infinite,” which is not terribly helpful (also, if you have a union too large for SetTuple—I didn’t find its limit but I’m pretty sure it’s got one—you’ll get exactly the same error and won’t be able to distinguish “my union is too large” from “my tuple is wrong.” I still think the separate trio of statements is superior, but this does work.