A codebase types its navigation helper as `function navigate(path: `/users/${string}`): void`. What does that annotation actually guarantee, and where does it stop helping?

## What the annotation buys ```ts declare function navigate(path: `/users/${string}`): void; navigate("/users/42"); // ok navigate("/user/42"); // error — prefix does not match navigate("/orders/42"); // error ``` Every call the checker analyses with a precise enough argument type is verified against the prefix. That is genuinely valuable: it catches the typo class of bug (`/user/` versus `/users/`) at the place the path is written, and editors offer the prefix as you type. Compared with `path: string`, the annotation moves a whole family of mistakes from a 404 in staging to a red squiggle. ## How the argument's type is produced decides everything The check is on the *type*, so the way the string is built matters more than what it contains: ```ts declare const id: string; navigate(`/users/${id}`); // ok navigate("/users/" + id); // error: string is not assignable const p1 = `/users/${id}`; // inferred as string navigate(p1); // error const p2: `/users/${string}` = `/users/${id}`; navigate(p2); // ok ``` Two mechanics are at work. A template string expression that is *contextually typed* by a template literal type is itself inferred as a template literal type, which is why the direct call succeeds. Without that context — assigned to a bare `const`, or built with `+` — the expression widens to `string`, and `string` is not assignable to the narrower pattern. Annotating the intermediate binding restores the context. This is the friction point in real adoption. Developers hit the error on a concatenation, do not understand why the template string version works, and reach for `as` — at which point the annotation has been converted into decoration. ## The boundary problem The deeper limit is that a large share of paths in a real app do not originate in code: ```ts const target = searchParams.get("redirect"); // string | null const route = config.defaultRoute; // string from JSON const link = cmsBlock.href; // string from an API ``` All of these are `string`. The pattern cannot check them, because there is nothing at compile time to check. The two honest responses are a runtime guard or a deliberate assertion: ```ts function isUserPath(s: string): s is `/users/${string}` { return s.startsWith("/users/"); } if (isUserPath(target)) { navigate(target); // narrowed, and the check actually ran } ``` The predicate is a promise the compiler trusts, so its body must genuinely test what the signature claims. Compare with `navigate(target as `/users/${string}`)`, which performs no check at all and silences the one signal you had. For a redirect target the difference is not cosmetic — an unvalidated path is how open-redirect bugs get shipped. ## Erasure sets the ceiling After compilation the annotation is gone: `navigate` receives whatever string the caller produced, and there is no prefix test in the emitted function. So the type constrains authorship, not execution. Any path that crosses a runtime boundary — user input, storage, the network — is outside the guarantee by construction, and only code you write can close that gap. ## Judgment: how far to push it A reasonable position for a production codebase: - **Use the pattern for internally constructed paths.** Cheap to write, catches typos, no compile-time cost worth mentioning. - **Validate once at each boundary** with a type predicate, then let narrowing carry the precise type inward. One check, many typed uses. - **Treat every `as` on a path as a defect to justify.** If a cast is needed, the missing piece is usually a boundary check that was never written. - **Be sceptical of full path parsing.** Extracting parameter names from a route with recursive `infer` is impressive and occasionally right, but it is compile-time work on every keystroke, produces error messages nobody can read, and stops being maintainable when one person leaves the team. Prefer a hand-written parameter type next to the route constant unless the route table is large and genuinely volatile. - **Remember the type is not the router.** If the router accepts arbitrary strings at runtime, the strong signature is a lint on your own code, not a security control. The honest summary to give an interviewer: the annotation is a cheap, high-yield check on strings your code builds, and provably nothing on strings your code receives.