In TypeScript, what type does `if (Array.isArray(x))` narrow `x: unknown` to, and why is that a hole in an otherwise strict codebase?

## The declaration behind the behaviour The built-in check is declared in the standard library as a type predicate: ```ts interface ArrayConstructor { isArray(arg: any): arg is any[]; } ``` Narrowing always produces the predicate's stated type, so applying it to an `unknown` gives `any[]`: ```ts function handle(x: unknown) { if (Array.isArray(x)) { // x: any[] x[0].whatever.deeply.nested; // compiles, no complaint } } ``` The branch is exactly where a careful codebase most wants precision — the value came from outside and has just been established to be an array — and it is the one place the checker stops helping. ## Why no flag catches it The strictness flags that police `any` are about *implicit* occurrences: a parameter or variable with no annotation that the compiler had to fall back on. Here the `any` is explicit, correct as a declaration, and lives in the library's own type definitions. Nothing in your source has an unannotated position, so nothing is reported. The `any` propagates outward from the branch through every expression derived from an element, and each of those expressions also stops being checked. This is the general shape of the `any` hazard — it is contagious, and one entry point disables checking for everything downstream of it. Why is the library declared that way? Because the check genuinely proves only array-ness. `unknown[]` would be the honest element type, but it would break a great deal of existing code that reads elements straight out of the narrowed value, so the declaration favours compatibility. ## Unions are the easy case When the input is a union, the guard behaves like any other predicate and simply filters the constituents: ```ts function lines(v: string[] | string): string[] { if (Array.isArray(v)) { return v; // v: string[] — element type preserved } return v.split("\n"); // v: string } ``` The element type survives because narrowing keeps the declared constituent rather than replacing it with the predicate's type. So the trap is specific to narrowing from `unknown` or `any` — that is, exactly the untrusted-input case. ## The fix Wrap the check once, in a helper whose predicate tells the truth: ```ts function isUnknownArray(x: unknown): x is unknown[] { return Array.isArray(x); } function handle(x: unknown) { if (isUnknownArray(x)) { // x: unknown[] for (const item of x) { if (typeof item === "string") { // item: string } } } } ``` Now the compiler forces a per-element guard before anything is used, which is the check you should have been writing anyway. The same wrapper is what a validation library gives you at its boundary; if the codebase already runs a schema validator on inbound data, that layer supersedes this one entirely. ## The other half: what the guard proves The check establishes array-ness and nothing else. It says nothing about length, about element types, or about whether the array is homogeneous. It also excludes `null` on its own, which makes it a cleaner alternative to an object-tag test when what you actually want from a nullable union is the array member. And, like every guard here, it is erased in one direction only: the call itself is real JavaScript that survives compilation, while the narrowed type is bookkeeping that ends at emit. ## Interview framing Name the declared predicate, state that narrowing an `unknown` therefore yields `any[]`, and explain why no flag reports it — that is the part that separates a candidate who has read the library declarations from one who has only used the API. Then give the one-line wrapper as the fix, and note that narrowing a union was never affected.