Lesson 22 of 80

Declaration Merging & Module Augmentation

Q: How would you add a custom `user` property to Express's Request type without forking or editing the library's source?

A strong answer covers: Declaration merging: multiple interface declarations with the same name combine into one; Use module/global augmentation (declare global { namespace Express { interface Request { ... } } }) to add the property from your own code; This works because interface supports merging; type aliases explicitly do not.

Two interfaces with the same name aren't a conflict — TypeScript combines them into one. A quirky-sounding rule that turns out to be exactly how you safely extend a third-party library's types.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

You declare `interface User { name: string }` and later, elsewhere, `interface User { age: number }`. What happens?

They merge into one interface with both name and ageTypeScript throws a duplicate identifier errorOnly the second declaration is used; the first is silently discarded

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Declaration Merging & Module Augmentation

What interviewers actually ask about this, and what a strong answer has to cover.

How would you add a custom `user` property to Express's Request type without forking or editing the library's source?

A strong answer covers

Declaration merging: multiple interface declarations with the same name combine into one
Use module/global augmentation (declare global { namespace Express { interface Request { ... } } }) to add the property from your own code
This works because interface supports merging; type aliases explicitly do not

Likely follow-ups

What happens if your augmentation tries to redeclare an existing property with an incompatible type?
Why does this only work with interface and not type?
Where would you typically put this kind of augmentation file in a real project?

Practice these with the AI interviewer →

The plain-language idea

interface User { name: string }
interface User { age: number }

const u: User = { name: "Ada", age: 36 };  // has both — the two declarations merged

Two interface declarations with the same name merge into one interface with all their combined members, instead of the second one conflicting with (or overwriting) the first. This is a deliberate, useful feature — and it's exactly why the interfaces-vs-types lesson's "interfaces can be merged, type aliases can't" distinction matters in practice, not just as trivia.

The real-world use: extending a library's types

// your app's types file
declare global {
  namespace Express {
    interface Request {
      user?: { id: string };   // adds a `user` property to Express's Request type
    }
  }
}

Express's own Request interface didn't originally have a user field — auth middleware adds one at runtime, but the type needs to know about it too. Declaration merging lets you augment a library's existing types from your own code, without forking the library or editing its source — the two declarations (theirs and yours) merge into one, and every file that imports Request sees the combined shape.

Declaration merging: interfaces combine, they don't collideStep 1 of 3

interface Window { myGlobal: string; } — declared once, here.

What people usually miss

Watch out

This is the standard way to type an untyped or partially-typed third-party library — writing your own .d.ts file with matching interface names to add or correct what the library ships.
Function and namespace declarations merge too, not just interfaces — a function declaration and a namespace with the same name combine so the namespace's exports become properties on the function.
Merging combines members, it doesn't let you override an existing member's type — adding a new property named user is fine; redeclaring an existing property with an incompatible type is a real conflict TypeScript will flag.

Why this matters in interviews

"How would you add a custom property to Express's Request type without forking the library?" is a genuinely common real-world TypeScript problem, and declaration merging via module augmentation is the concrete, correct answer.