You want one TypeScript helper, invariant(condition, message), that throws when the condition is falsy and also narrows types for the code that follows. What signature makes that work, and what does a call like `invariant(typeof id === "string")` narrow?

## The bare assertion form Assertion signatures come in two shapes. `asserts value is T` claims a specific type for a parameter. The bare form, `asserts condition`, claims only that the named parameter was *truthy* if the call returned. That second shape is what a general-purpose invariant helper needs, because the caller supplies the condition and the helper has no idea what type is being established. ```ts function invariant(condition: unknown, message?: string): asserts condition { if (!condition) throw new Error(message ?? "invariant failed"); } ``` The parameter type matters. Declaring `condition: unknown` lets any expression be passed — a possibly-null object, a string, the result of a `typeof` comparison — without a cast at every call site. Declaring it `boolean` would force callers to coerce, and callers who write `invariant(user)` to mean "user is not null" would be rejected. ## What actually gets narrowed The key insight is that the compiler does not narrow the *parameter*; it narrows whatever references the *argument expression* mentions, exactly as if that expression had been an `if` condition. Three common cases: ```ts declare const id: unknown; invariant(typeof id === "string"); id.toUpperCase(); // id: string declare const user: { name: string } | null; invariant(user); user.name; // user: { name: string } declare const p: string | null; declare const q: number | null; invariant(p && q); p.length; // p: string q.toFixed(1); // q: number ``` This is why the bare form is so much more useful than it first looks: one helper covers null checks, `typeof` checks, discriminant comparisons and compound conditions, because it inherits the whole narrowing machinery from ordinary conditionals. Contrast it with a signature that looks similar and does nothing useful: `asserts condition is boolean` narrows the *condition value* to `boolean`, which nobody cares about, and leaves `id` untouched. If you write `is` after the parameter in an invariant helper, you have broken it. ## The mechanics that trip people up The helper must be a function declaration, or a `const` annotated with an explicit function type. An un-annotated arrow assigned to a `const` is rejected at every call site, because the checker will not infer a callee's signature while applying a call's control-flow effect. The call target must also be a plain identifier or a dotted name. `invariant(...)` and `assertions.invariant(...)` work; a callee pulled out of a map or produced by a conditional expression does not, since there is no name to resolve. The optional `message` parameter is ordinary — it plays no part in the assertion. Keep it lazy if building the message is expensive: pass a string only when cheap, or accept a `string | (() => string)` and call it in the failing branch. ## Judgment: what the type claim is worth An assertion signature is a promise the compiler accepts without inspection. For an invariant helper that promise has an unusual dependency: it holds only as long as the body genuinely throws for every falsy condition. Two ways teams break it in production and are then surprised by the crash site. The first is stripping. If the helper is compiled away or turned into a no-op in production builds — a common trick for assertion libraries, aiming to shed bytes — then the runtime check disappears while every downstream line keeps its narrowed type. The failure no longer surfaces at the invariant with its message; it surfaces later, as a property access on `undefined`, in code the checker had certified. If a build ever removes the check, the narrowing it justified should be considered removed with it. The second is a body that reports instead of throwing — logging, incrementing a metric, returning early behind a feature flag. Any path that returns normally tells the checker the condition held. There is also a modelling cost to weigh. A single `invariant` is a blunt instrument: it narrows, but the *reason* lives only in the message string. Where a specific shape is being established repeatedly, a named assertion with `asserts value is T` documents intent better and gives you one place to change the check. A reasonable convention is `invariant` for local, one-off preconditions, and named assertion functions for domain types crossing a boundary. ## Erasure, as always Nothing here exists at runtime. The emitted JavaScript contains your `if (!condition) throw ...` and nothing else; `asserts condition` vanishes with every other type annotation. All the narrowing is knowledge inside the checker, which is exactly why the runtime behaviour of the body has to be kept honest by hand.