FizzBuzz as a TypeScript type

There's this type that I have used in many projects.

/**
 * Converts a type into its post JSON serialization/de-serialization version.
 */
type JSONSerialized<T> =
  // We first check if we're looking at a primitive type. Primitives will be passed
  // through untouched by `JSON.parse(JSON.stringify(...))`, so `JSONSerialized` replicates
  // that behavior. The exact `T` type is output instead of `number` or `string` in case
  // the type is actually a union (ex: "foo" | "bar"). This way the union is preserved.
  T extends number ? T :
  T extends string ? T :
  T extends boolean ? T :
  T extends null ? null :
  // If we aren't looking at a primitive, then we'll next check if we're working with an
  // array. If so we convert the array's element type using a recursive type call.
  T extends (infer Elem)[] ? JSONSerialized<Elem>[] :
  // Here's the magic that takes care of `Date`s. Some types have a `toJSON` function.
  // `JSON.stringify` will call this function if it doesn't already know what to do with
  // a value. By using `infer` we can dynamically extract the return type of a `toJSON()`
  // as defined on ANY type - including `Date.toJSON`.
  T extends { toJSON: () => infer Return } ? Return :
  // Lastly, check if we're working with an Object and if so, iterate through its
  // key/value pairs - sending each value into a recursive call to `JSONSerialized`.
  T extends { [Key in keyof T]: T[Key] } ? { [Key in keyof T]: JSONSerialized<T[Key]> } :
  never;

It's employed when importing HTTP response types from the back end code into the front end code. If your back end function returns something like:

export function handler() {
  return { timestamp: new Date() };
}

You can't cast the HTTP response's natural any type to ReturnType<typeof handler> as that will be incorrect. After this has gone through JSON.stringify() -> JSON.parse() the timestamp field is an ISO formatted string, not a Date. So the type above walks through any response type and converts it to how it will look in the front end. This is used in concert with other TypeScript code which combined eliminates the need for something like GraphQL for HTTP client code generation. It's still REST - so not a true replacement for GraphQL. Although I prefer it that way.