In TypeScript, what does declaring a `namespace` with the same name as an existing interface, class, or function give you, and what ordering rule applies?

## Declaration spaces are what make this work Every TypeScript declaration contributes to one or more of three spaces: **type**, **value**, and **namespace**. An `interface` contributes a type only. A `function` or `const` contributes a value only. A `class` contributes both a type (its instance type) and a value (its constructor). A `namespace` contributes a value — the object it emits — and a namespace-space entry for anything declared inside it. Two declarations collide only when they claim the same space. That is why a namespace can share a name with an interface, a class, a function or an enum: the pieces slot into different spaces and the compiler merges them into one symbol. ## Namespace plus interface: the companion pattern ```ts interface Point { x: number; y: number; } namespace Point { export const origin: Point = { x: 0, y: 0 }; export function equals(a: Point, b: Point): boolean { return a.x === b.x && a.y === b.y; } } const p: Point = Point.origin; // Point used as a type and as a value ``` The interface supplies the type; the namespace supplies helpers under the same name. Callers get one import and one concept instead of `Point` and `PointUtils`. This is a common way to package a type with its constructors and predicates. ## Namespace plus class, function or enum Merging a namespace with a class adds members to the class's *static* side and lets you nest types under the class name. Merging with a function attaches properties to the function value — the type-layer counterpart of the everyday JavaScript habit of hanging fields on a function object. Merging with an enum adds helpers alongside the enum members. Here an ordering rule applies: **the namespace must follow the class, function or enum it merges with.** The reason is emit. A namespace containing values compiles to an immediately-invoked function that augments an existing binding, so that binding must already exist when the namespace's code runs. Interfaces are exempt because they emit nothing at all, so there is no runtime ordering to respect. ```ts function greet(name: string): string { return `hello, ${name}`; } namespace greet { // must come after the function export const locale = 'en'; } console.log(greet('Ada'), greet.locale); ``` ## Only exported members are visible A namespace's members are private unless declared with `export`. A non-exported `const` inside the block is a genuine implementation detail — usable by the other members of that namespace, invisible through the merged name. When two namespace declarations of the same name merge, the same rule governs what each can see of the other: exported members are shared, non-exported ones stay local to their own block. ## What is emitted This is where the tree's central rule shows up. A namespace containing only types is erased completely — nothing reaches the output. A namespace containing values emits an object and assignments into it, so it is one of the few type-layer-looking constructs that has a runtime footprint, along with `enum`. Merging with an interface therefore costs nothing at runtime unless you put values in the namespace. ## What never merges Not every pairing is legal, and it is worth being precise: - **Class with class** — a duplicate identifier. Both claim the value space and the type space. - **Type alias with anything of the same name in the type space** — a duplicate identifier; aliases are closed. - **Function with function**, absent overload syntax — two implementations of the same name collide. And one pairing that does merge but is easy to overlook: an `interface` declaration merges with a **class** of the same name, contributing members to the class's instance type. That is the mechanism the mixin pattern relies on to tell the checker about members added dynamically. ## Judgment Namespaces used as a *module system* are legacy — modern TypeScript code organises code with ES modules, and a file-level `namespace` wrapper adds nesting for no gain. Namespaces used for *merging*, though, remain the idiomatic way to express "this name is both a type and a small set of values", and there is no ES-module equivalent that gives one identifier both roles. In a module you can achieve much of the companion effect by exporting a type and a const object of the same name from the same file, since a type and a value can share a name without conflict — but nested types under a value name still need the namespace form.