In TypeScript, when two same-name interface declarations each declare a member called `format`, when is that a compile error and when do you get an overload set?

## Two member kinds, two rules When the compiler merges same-name interfaces it does not simply concatenate members. It applies one rule to method-shaped members and a stricter rule to everything else. **Method syntax** — `format(value: string): string` — declares a call signature attached to a name. Several declarations of the same method name across merged interfaces are legal and become **overloads** of one function: ```ts interface Fmt { render(value: string): string } interface Fmt { render(value: number): string } // Fmt.render now has two call signatures. ``` **Property syntax** — `format: (value: string) => string`, or any non-method member like `count: number` — declares a property whose type happens to be a function type. Here the rule is: names must be unique across the merged declarations, or, if repeated, must be declared with the *same* type. Repeating a property with a different type is an error stating that subsequent property declarations must have the same type, naming both the expected and the found type. This is the distinction that surprises people. These two members look interchangeable when you write the interface, and for assignability purposes they are close cousins — but for merging they behave completely differently. If you want an interface that stays open to additional signatures, declare the member with method syntax; if you want a member nobody can quietly extend, declare it as a function-typed property. ## Repetition is allowed when the types match Merging does not require the declarations to be disjoint. Declaring `id: string` in both halves is legal and produces one `id: string`. That matters for augmentations: two independent packages may both add the same member, and as long as they agree on the type, the program still compiles. The moment they disagree, somebody has to resolve it — there is no precedence rule for properties, no last-one-wins, and no way to scope one of them away. ## Order of the merged overload list Overloads are ordered, because resolution picks the first signature that matches. In a merged interface, members contributed by the **later** declaration are placed **before** those of earlier declarations in the merged list. So if a package declares an interface and your augmentation adds another `render` signature, yours is considered first. There is one refinement to know: a signature whose parameter type is a single string literal is a *specialized* signature and is hoisted toward the top of its overload list, so it is checked before more general signatures. That is what makes DOM-style APIs work, where a call with a specific literal argument gets a precise return type while the general signature catches everything else. The practical reading: overload order in a merged interface is not fully in the original author's hands. An augmentation loaded later can shadow an existing signature for calls that both would accept. When a call resolves to a surprising signature, the merge order is where to look. ## Why the rules are asymmetric Overloading is meaningful only for callables — you can describe the same operation several ways. A data property has one type; two contradictory declarations of the same property would leave the checker with no consistent answer, so it refuses. Nothing here is a runtime mechanism: merged overloads are erased along with the rest of the type layer, and the overload set only ever influenced which signature the checker used to check a call site. ## Conflict in practice The usual place these rules bite is augmentation. Two libraries in one program both extend a widely-used interface — a request object, a config object, a global — and both choose the obvious member name: ```ts // library A's augmentation interface AppContext { user: string } // library B's augmentation interface AppContext { user: { id: string } } // error: types must match ``` The build fails with no obvious owner: neither package is wrong, and you cannot un-apply one of them, because merging is program-wide. The mitigations are all preventative — namespace your added members (`myFeature: { ... }` rather than a bare common noun), keep additions optional so they describe reality, and prefer a local wrapper type when the extension is only for your own code. A second, quieter failure is the overload one: two packages add signatures for the same method, both match a given call, and the one loaded later silently wins. There is no diagnostic for that — the code compiles and the inferred return type is simply not the one you expected. Reading the merged signature list in an editor tooltip is usually the fastest way to see what actually happened.