This TypeScript code fails to compile: `declare function request(url: string, method: 'GET' | 'POST'): void; const config = { method: 'GET' }; request('/users', config.method);`. What type did the compiler infer for config.method, why, and how would you fix it?

## What actually got inferred Hover the two declarations and they differ in exactly the way that causes the error: ```ts const method = 'GET'; // type: 'GET' const config = { method: 'GET' }; // type: { method: string } ``` The second one is the whole question. The value written is identical; only the *place it lands* differs, and that place decides whether the literal type survives. ## Fresh literal types and widening When the checker types a literal expression such as `'GET'`, it does not immediately produce either `'GET'` or `string`. It produces a **fresh literal type** — the type `'GET'` carrying an internal flag that says "this came directly from a literal and is a candidate for widening". What happens next depends on the mutability of the target: - An **immutable** location keeps the literal type. A `const` binding of a primitive can never be reassigned, so `const method = 'GET'` is safely typed `'GET'`. - A **mutable** location widens the fresh type to its base primitive. `let method = 'GET'` is typed `string`, because the next line may legally assign a different string. An object literal's property is a mutable location. `const config` freezes the *binding* — you cannot write `config = somethingElse` — but it says nothing about the object's contents. `config.method = 'POST'` is perfectly legal JavaScript, so if the checker typed the property as `'GET'` it would have to reject that assignment, which would make ordinary mutable objects unusable. It widens instead, and the property becomes `string`. So the error message — `Argument of type 'string' is not assignable to parameter of type '"GET" | "POST"'` — is accurate and slightly maddening: the value clearly *is* `'GET'`, but its **type** is `string`, and the compiler only reasons about types. ## Why widening is the right default It is tempting to call this a design mistake. It is not. Without widening, ordinary accumulation code would be unwritable: ```ts let name = ''; // if this were type '', the next line could never compile name = loadName(); ``` Every mutable slot initialised with a literal would be locked to that one value forever. Widening keeps mutable code natural, and the escape hatches below let you opt out precisely where you want the narrow type. ## The three fixes **1. Annotate the object (or the property).** An explicit annotation is a *contextual type*, and a contextual literal-union type stops the widening: ```ts const config: { method: 'GET' | 'POST' } = { method: 'GET' }; request('/users', config.method); // ok — property is 'GET' | 'POST' config.method = 'POST'; // still allowed, still checked ``` This is usually the best choice for a value you intend to keep mutating: the property stays writable, but only with members of the union, and the intent is documented in the source. **2. `as const`.** Appending `as const` to the object literal tells the checker to treat everything inside as immutable, so no property widens: ```ts const config = { method: 'GET' } as const; // { readonly method: 'GET' } request('/users', config.method); // ok ``` Note the trade: the property is now `readonly` *and* pinned to the single value `'GET'`, not the union. That is what you want for a constant, not for a value you plan to reassign. **3. Pass the literal where the context already has a type.** At a call site the parameter's declared type supplies the context, so nothing widens: ```ts request('/users', 'GET'); // fine — checked against 'GET' | 'POST' directly ``` This is why the bug so often appears only after a refactor: the call worked inline, someone hoisted the arguments into a config object, and the literal type evaporated on the way. ## The same trap in other shapes Inferred return types widen the same way, because a returned expression is not landing in an immutable slot: ```ts function getMethod() { return 'GET'; } // inferred: () => string ``` If a caller needs the literal type, annotate the return type as `'GET' | 'POST'` (or as `'GET'`). Array literals behave analogously: their elements are mutable, so a literal array of strings infers as `string[]`. ## Nothing here exists at runtime Widening is purely a checker decision. The emitted JavaScript is the same object either way, and the `as const` version is not frozen — `readonly` is a compile-time modifier, not `Object.freeze`. If you need the object to be genuinely immutable at runtime, that is a separate, explicit call. ## What an interviewer is listening for The weak answer is "TypeScript is being annoying, just cast it". The strong answer names the mechanism — a fresh literal type widens in a mutable location — explains why `const` on the binding does not reach the property, and then picks a fix on purpose: annotation when the value stays mutable, `as const` when it is genuinely a constant.