A generic TypeScript helper produces an error message that runs for pages and is cut off with `...`. Why do computed types fail this way, and how do you get the errors under control?

## Why the message looks like that Three behaviours combine. **Computed types lose their names.** `Partial<User>` is printable as a name only while it is unevaluated. Once a mapped or conditional helper has been instantiated, what the checker holds is the resulting structure. When it needs to describe that structure in an error, it prints the members — all of them, nested — because there is no shorter accurate name. **The error surfaces where it was noticed, not where it was caused.** Assignability failures are reported at the outermost check that failed. If a wrong type argument three layers in eventually produces a shape that does not match a parameter, the squiggle lands on the call, and the message describes a mismatch between two enormous structures rather than saying "you passed `id` as a `number`". **Type text is truncated.** To keep messages bounded, the compiler shortens long type text and prints `...`. That is a kindness in normal use and a disaster when the difference you needed to see was in the truncated part. ## Getting it under control **Name intermediate steps.** A helper written as one 15-line expression can only be printed as the expanded result. The same logic split into a few named aliases gives the compiler names to use, and gives you a place to hover and inspect each stage. **Constrain the type parameters.** An unconstrained `T` accepts anything and fails deep. `T extends Record<string, unknown>` rejects a bad argument at the boundary, and the message is one line about the constraint rather than a wall about the result. **Annotate the receiving value.** Assigning to a variable with an explicit type moves the check to your declaration, so the error appears on the line you can actually fix. **Reduce to a minimal case.** Copy the helper into a scratch file, apply it to a three-property type, and hover the result. Reading a small expansion beats parsing a large one, and the reduction usually exposes the bug before the error does. **Use a prettifier for hovers.** The community idiom below forces the compiler to re-map an intersection into a single flat object, which reads much better in tooltips: ```ts type Prettify<T> = { [K in keyof T]: T[K] } & {}; type Messy = { a: string } & { b: number }; type Clean = Prettify<Messy>; // hovers as { a: string; b: number } ``` **Turn off truncation when you must.** `tsc --noErrorTruncation` prints type text in full. Expect a very long message — this is a deliberate act for one investigation, not a setting to leave on. **Pin the behaviour with type tests.** If a helper is worth its complexity, it is worth tests. `@ts-expect-error` on a line that must fail to compile is the zero-dependency option; the `expect-type` and `tsd` packages give you richer assertions. Tests turn "the error changed and I don't know if that's bad" into a failing check. ## The judgment underneath An interviewer asking this is usually less interested in the flag than in whether you treat error readability as part of a type's cost. A helper is used by teammates who did not write it, and its error message *is* its user interface. If a one-character mistake in a caller yields four hundred lines of type text, the helper is expensive regardless of how elegant the definition is, because every future encounter with it costs somebody an hour. That leads to a reasonable rule for shared code: if you cannot produce a decent failure message for the common mistake — by constraining, splitting, or documenting — prefer the plainer explicit type. And if the property you were trying to enforce is really about data arriving from outside the program, no type-level message will help anyway, because the check has to happen at run time. ## A quick worked pattern Faced with the page-long error, the fastest reliable sequence is: annotate the value you are assigning so the error moves to your line; if it is still opaque, extract the exact type arguments into named aliases and hover each; if it is still opaque, reduce to a scratch file with a tiny input type; and only then reach for `--noErrorTruncation` to read the full text. Most of the time the second step ends it.