Alright, let’s get our hands dirty with the two features in TypeScript 4.x that made a lot of us sit up and say, “Wait, they can do that now?” We’re talking about Template Literal Types and Variadic Tuples. These aren’t just incremental tweaks; they’re fundamental shifts that let you express types with a precision that was pure fantasy in earlier versions. They’re the reason you can now build types that feel like they’re almost reading your mind.

The Power of String Manipulation at the Type Level

Remember string literal types? The ones that let you define a type as "admin" | "user" | "guest"? They were useful, but frankly, a bit dumb. They just sat there. Template Literal Types are their clever cousin who went to a fancy university and learned how to manipulate strings, not just list them.

The syntax is deliberately identical to JavaScript’s template literals, but it’s used in type position. This means you can combine string literals, other string types, and even pull in primitive types.

type Status = "idle" | "loading" | "success" | "error";
type HttpVerb = "GET" | "POST" | "PUT" | "DELETE";

// Let's create some more complex message types
type StatusMessage = `The status is ${Status}`;
// ^ type is: "The status is idle" | "The status is loading" | ... 

type ApiEndpoint = `/api/v1/${string}`;
// A generic catch-all for our API routes

type SpecificEndpoint = `/api/v1/${HttpVerb}_${string}`;
// More constrained: must start with a known HTTP verb

The real magic, the part that makes this more than a party trick, is when you combine it with generics and conditional types. You can write a type that extracts a part of a string or validates its format. It’s like having a tiny regex engine inside your type system.

// A classic example: making keys for a hypothetical event emitter
type Event = "click" | "drag" | "keydown";
type Modifier = "ctrl" | "shift" | "alt";

type EventKey = `${Modifier}+${Event}` | Event;
// type is: "click" | "drag" | "keydown" | "ctrl+click" | "shift+click" | ... etc.

// Now, let's say we get a string and want to infer the parts.
// We can use a conditional type with infer.
type ExtractModifier<T extends string> = T extends `${infer M}+${infer E}` ? [M, E] : [null, T];

type Test1 = ExtractModifier<"ctrl+click">; // type is ["ctrl", "click"]
type Test2 = ExtractModifier<"drag">;        // type is [null, "drag"]

The most common pitfall here is hitting the recursion limit or creating a union type so massive it makes your IDE weep. TypeScript is smart, but it’s not infinitely smart. If you try to create a union of thousands of possible strings, you’ll have a bad time. Use constraints (extends string) wisely.

Taming Function Argument Lists with Variadic Tuple Types

Before TS 4.0, typing function arguments was often a game of “how many overloads can I write before I give up and use any”. Variadic Tuples fixed that. They let you represent the types of argument lists (tuples) that can be of varying lengths and types, and even include spread elements. It’s the ...rest operator for types.

Think of it as the type system finally understanding the concept of “and then a list of other stuff.”

// The classic example: a function that prepends or appends to a tuple.
type Prepend<T, U extends any[]> = [T, ...U];
type Append<T, U extends any[]> = [...U, T];

type NewTuple = Prepend<number, [string, boolean]>; // type is [number, string, boolean]
type AnotherTuple = Append<string, [number, boolean]>; // type is [number, boolean, string]

// This is powerful because it works with generics. Let's create a smarter "concat"
function concat<T extends any[], U extends any[]>(a: [...T], b: [...U]): [...T, ...U] {
    return [...a, ...b];
}

const result = concat([1, "hello"], [true, 42]);
// result has the type: [number, string, boolean, number]
// Not (number | string | boolean)[], a precise tuple!

This is the secret sauce that made typing Promise.all, Function.bind, and other notoriously tricky built-ins finally accurate. You can now properly express “the first argument is a string, and the rest are these other things, and the return type depends on all of it.”

Here’s the best practice and the biggest “gotcha” rolled into one: Always use the spread syntax [...T] in your variadic tuple definitions, not just T. The [...T] syntax is what tells TypeScript you’re explicitly working with a tuple structure that can be manipulated. Using just T often falls back to treating it as an array, which loses all the precious order and length information you’re trying to preserve.

Combining these two features is where the real art happens. Imagine a function that takes a URL with a pattern and returns an object with parsed parameters. With Template Literal Types to describe the URL pattern and Variadic Tuples to handle the resulting argument list, you can build a type-safe router that feels like magic. It’s not easy, but the fact that it’s even possible is a testament to how far TypeScript has come. This is no longer a tool just for catching typos; it’s a system for describing and enforcing the architecture of your application, right there in your code.