Что будет, если создать два интерфейса с одинаковым именем в одном файле

В TypeScript интерфейс можно объявить несколько раз в одной области видимости. Компилятор не считает это переопределением. Он складывает объявления в один интерфейс.

interface User {
  name: string;
}

interface User {
  age: number;
}

const user: User = {
  name: "Alice",
  age: 25,
};

Практический вывод для интервью простой: объект типа User должен соответствовать полному объединенному контракту. Если вы скажете, что второй интерфейс заменит первый, пример выше сразу покажет ошибку в понимании.

Declaration merging не означает, что TypeScript сам придумает безопасный компромисс. Если два объявления описывают одно и то же свойство несовместимо, это ошибка типов.

Плохой пример:

interface User {
  id: string;
}

interface User {
  id: number;
}

TypeScript не сделает id типом string | number и не выберет последнее объявление. Вам нужно явно решить, каким должен быть контракт. Например, оставить один тип id, переименовать поле или создать отдельную модель для другого слоя данных.

Само merging не создает runtime-код, но оно меняет то, что TypeScript считает допустимым контрактом. Поэтому риск во frontend часто появляется на границе с реальными данными. Это ответ API, localStorage, query params, данные из CMS или props, которые собираются в разных местах приложения.

Плохой пример:

interface ApiUser {
  id: string;
  name: string;
}

interface ApiUser {
  avatarUrl: string;
}

После такого расширения компонент может поверить, что avatarUrl всегда есть. Но сервер не начнет присылать поле из-за TypeScript. Последствие: сломанная картинка, пустой alt-текст, неверный loading или empty state, иногда неверная аналитика по отображению профиля.

Безопаснее держать DTO ответа рядом с API-клиентом, валидировать внешние данные на границе и явно превращать их в модель UI. Если поле реально опционально, отразите это в типе и добавьте fallback в компоненте.

В ответе хорошо отделить знание механики от стиля кода. Declaration merging полезен, когда вы расширяете уже существующий тип. Особенно тип из библиотеки или глобальный интерфейс. Например, добавляете свое поле в тип сессии, роутера или глобального объекта через поддерживаемый механизм расширения.

Но если вы просто моделируете данные приложения, два одноименных интерфейса могут запутать команду. Читателю придется искать все объявления, чтобы понять полный набор полей. В таких случаях прозрачнее написать extends, пересобрать тип явно или выбрать более точное имя.

Вопрос часто звучит как "в одном файле". Там правило проще: если объявления в одной области видимости, интерфейсы объединятся. Но сильный ответ может добавить, что в больших frontend-проектах важна именно область объявления.

Если файл является ES-модулем, то есть содержит import или export, его top-level объявления живут в области этого модуля. Такой interface User не обязан объединяться с таким же именем в другом модуле. Для расширения глобальных типов или типов библиотек используют явные конструкции, например declare global или module augmentation.

Это важно на практике. Случайный глобальный интерфейс может расшириться из другого файла и сломать проверки в неожиданном месте. А надежда на merging между модулями может не сработать. Тогда код выглядит расширенным только в голове автора.

Не переносите правило интерфейсов на все конструкции TypeScript. Два type с одинаковым именем в одной области видимости не объединятся. Два класса с одинаковым именем тоже не станут одним классом.

type User = {
  name: string;
};

// Плохой пример: так нельзя повторно объявить type alias с тем же именем.
type User = {
  age: number;
};

Если нужен явный составной тип, можно написать новый alias:

type NamedUser = {
  name: string;
};

type UserWithAge = NamedUser & {
  age: number;
};

Если нужен читаемый интерфейс-наследник, используйте extends. Это не то же самое, что merging, но для доменных моделей часто понятнее.