A codebase fetches JSON with `async function getJson<T>(url: string): Promise<T> { const res = await fetch(url); return res.json(); }`. Why is this signature a type-safety hole, and what would you return instead?

## Why the signature compiles ```ts async function getJson<T>(url: string): Promise<T> { const res = await fetch(url); return res.json(); } const user = await getJson<User>('/api/me'); // user: User, checked by nobody ``` Two things make this work, and both are worth naming in an interview. First, **`T` is an unconstrained, uninferable type parameter**. It appears in no parameter position, so there is no argument for the compiler to infer it from. The only input is what the caller writes — `getJson<User>(...)` or `const u: User = await getJson(...)`. A type parameter that only appears in the return type is not generic programming; it is a request form for a cast. Second, **`Response.json()` is declared as `json(): Promise<any>`** in TypeScript's DOM library. `any` is assignable to every type, so returning it satisfies `Promise<T>` for any `T` whatsoever. The `any` never surfaces in a diagnostic — it is absorbed silently and re-emerges as a fully-typed value. This is the classic `any` funnel: one weakly-typed API at the boundary, one generic wrapper, and the entire codebase downstream believes it has checked data. ## Why this is worse than an ordinary cast An `as` is at least visible at the point of the lie. This helper moves the lie into a shared utility and then multiplies it: every feature team calls it, each supplies a different `T`, none of them writes a check, and the code review that would have flagged `as User` never happens because the call site looks impeccable. The compiler now vouches for `user.profile.email` in a hundred places on the strength of a server contract nobody validated. When the API renames a field or an error envelope comes back with the 200, the `TypeError` lands in a component that never heard of `getJson`. ## The fixes, in increasing order of honesty **Return `unknown`.** The minimal change, and it costs no dependency: ```ts async function getJson(url: string): Promise<unknown> { const res = await fetch(url); return res.json(); } const raw = await getJson('/api/me'); if (!isUser(raw)) throw new Error('bad /api/me payload'); raw.email; // narrowed, and the narrowing was earned ``` `unknown` is the honest type of bytes you have not inspected: you cannot read a property, call it, or pass it where a `User` is wanted until you narrow it. The type system now *forces* the guard rather than suggesting one. The cost is that every call site must handle failure — which is the point, not a regression. **Take the parser as a parameter.** Keeps the generic, but earns it: ```ts async function getJson<T>(url: string, parse: (raw: unknown) => T): Promise<T> { const res = await fetch(url); return parse(await res.json()); } const user = await getJson('/api/me', parseUser); ``` Now `T` is inferred *from the parser's return type*, so the only way to get a `User` out is to pass something that produces one from `unknown`. The signature can no longer be satisfied by wishful thinking, and a schema library's parse function drops straight into that slot. **Check the response before the body, too.** `fetch` does not reject on 4xx/5xx, so a helper that goes straight to `.json()` will happily hand you a parsed error envelope typed as your success shape. Inspect `res.ok` and the status before parsing. ## When the generic is defensible If the types are *generated* from the same source as the server's contract — an OpenAPI or GraphQL codegen pipeline, an internal RPC layer where both ends build from one schema — then the annotation is not a guess, and validating every payload may be paying twice. Even then the honest framing is "we validate at the schema-generation boundary and trust it here", which is a decision with an owner. What is not defensible is hand-written `T`s over a hand-maintained API, which is the situation this helper is almost always found in. ## The interview point The question is not really about `fetch`. It is whether you can spot a type parameter that carries no evidence, and whether you know that `any` at a library boundary silently validates any generic signature you write over it. Recognising that `Promise<T>` here means exactly `Promise<any> as Promise<T>` is the whole answer.