In TypeScript, calling this helper reports "Assertions require every name in the call target to be declared with an explicit type annotation": `const assertIsString = (v: unknown): asserts v is string => { if (typeof v !== "string") throw new TypeError(); };`. Why is the call rejected, and how do you fix it?

## The error, precisely ```ts const assertIsString = (v: unknown): asserts v is string => { if (typeof v !== "string") throw new TypeError("not a string"); }; declare const raw: unknown; assertIsString(raw); // error TS2775: Assertions require every name in the call target // to be declared with an explicit type annotation. ``` Two details catch people out. First, the *declaration* is fine — writing an assertion return type on an arrow function is legal, and the compiler says nothing about it. The complaint appears at the call site, which is why the error often looks like it is about the wrong line. Second, the message says "every name in the call target", not "the function" — that wording is doing real work, as the qualified-name case below shows. ## Why the rule exists An assertion call is not an ordinary call. It participates in control-flow analysis: the checker must decide what the code *after* the call knows. To do that it needs the callee's signature at the moment it walks the flow graph. If the callee is an un-annotated `const`, its type is not written down anywhere — it has to be inferred from the initializer, and that inference can itself depend on flow analysis. Rather than open a circularity, TypeScript declines and asks you to state the type. The practical shape of the rule: the compiler will follow a name to a *declared* type, but it will not run inference to obtain one. ## The two fixes A function declaration is the simplest answer. Its signature is the declaration; nothing needs inferring. ```ts function assertIsString(v: unknown): asserts v is string { if (typeof v !== "string") throw new TypeError("not a string"); } ``` If you prefer arrow functions, annotate the binding with a function type whose return type is the assertion signature, and let the initializer's parameters be contextually typed: ```ts const assertIsString: (v: unknown) => asserts v is string = (v) => { if (typeof v !== "string") throw new TypeError("not a string"); }; ``` Both forms narrow correctly at every call site. The second is noticeably more verbose, which is one reason assertion helpers are conventionally written as function declarations. ## Qualified names and the object-literal trap Because the requirement covers every name in the call path, grouping guards in an object hits the same wall: ```ts const guards = { assertIsString(v: unknown): asserts v is string { if (typeof v !== "string") throw new TypeError("not a string"); }, }; guards.assertIsString(raw); // TS2775 again ``` The method carries an explicit signature, but `guards` does not — its type came from inference over the object literal. Annotating the container fixes it: ```ts type Guards = { assertIsString(v: unknown): asserts v is string }; const guards: Guards = { assertIsString(v: unknown): asserts v is string { if (typeof v !== "string") throw new TypeError("not a string"); }, }; guards.assertIsString(raw); // narrows ``` There is a companion restriction on the *form* of the call target. It must be an identifier or a qualified (dotted) name — nothing computed. `guards["assertIsString"](raw)` is rejected with TS2776, "Assertions require the call target to be an identifier or qualified name". The same applies to a callee produced by a conditional expression or returned from another call: there is no name for the checker to resolve, so no assertion effect is applied. ## Imports behave the way you would hope — mostly Importing a helper does not weaken the rule; it just depends on how the helper was written in the other module. An imported `function` declaration works, because its signature is declared. An imported `const` holding an un-annotated arrow function fails at the call site with the same TS2775, in the importing file. So the fix belongs in the module that defines the guard, and getting it wrong there breaks every consumer. ## How this shows up in real code The symptom is usually not the error at all — teams that write assertion helpers as un-annotated arrow consts see the red squiggle immediately. The subtler failure is a codebase that standardises on arrow-function exports for stylistic reasons and then finds its guard helpers uniquely awkward. Knowing the rule turns a puzzling error into a one-line decision: use `function` for assertion helpers, or pay for the explicit function-type annotation.