TS TypeScript · 30 вопросов · ~85 мин · ⏱ Таймер 25:00 · Сложный ·

Ссылки проектов и монорепозиторий

Профессиональный тест по теме «Ссылки проектов и монорепозиторий»: сложные фрагменты кода, архитектурные компромиссы, диагностика и надёжность. Вопросы требуют читать код, сопоставлять статические гарантии с поведением JavaScript и выбирать решение, которое не рассыплется при развитии проекта.

Отвечено: 0 из 30

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. На 30 вопросов отведено 85 минут. Код читайте построчно: часть заданий проверяет не результат JavaScript, а то, что TypeScript способен доказать до запуска.

Вопрос 1 из 30

Что требуется от проекта, на который ссылается другой tsconfig?

{
  "compilerOptions": { "composite": true }
}

composite: true и явные входы проекта Глобальный namespace Только allowJs Обязательный noEmit Один общий outFile

Вопрос 2 из 30

Что означает references в приложении?

{
  "references": [
    { "path": "../domain" },
    { "path": "../infra" }
  ]
}

Только подсказки редактору без участия сборки Зависимости проектов, собираемые tsc -b по порядку Список npm-пакетов для установки Каталоги, исключённые из проверки Пути runtime-импортов, которые автоматически перепишутся

Вопрос 3 из 30

Почему зависимый проект обычно читает d.ts, а не исходники referenced-проекта?

// app references domain
import { User } from "@repo/domain";

User становится global d.ts выполняется быстрее в runtime Reference копирует весь код в один файл Исходники TypeScript нельзя импортировать Так потребитель проверяется по публичному выходу зависимости

Вопрос 4 из 30

Когда project references оправданы?

Чтобы автоматически запретить все циклы Чтобы заменить package manager Только при публикации npm Для частей с явным графом и дорогой сборкой Для любого проекта из двух файлов

Вопрос 5 из 30

Почему один корневой tsconfig с include всего монорепозитория слабее?

Корневой tsconfig не поддерживает strict Он не видит node_modules Он всегда создаёт один JavaScript-файл include запрещён в монорепозитории Он смешивает среды, зависимости и скрытые импорты

Вопрос 6 из 30

В показанном фрагменте что делает tsc -b?

// Фрагмент для анализа
tsc -b packages/app

Запускает bundler для браузера Устанавливает workspace-пакеты Строит граф зависимостей и пропускает актуальные проекты Удаляет все dist Проверяет только app без зависимостей

Вопрос 7 из 30

Для чего incremental/tsBuildInfoFile?

{
  "compilerOptions": {
    "incremental": true,
    "tsBuildInfoFile": "./.cache/domain.tsbuildinfo"
  }
}

Хранит данные для пересчёта только затронутых файлов Кэшировать результаты HTTP Публиковать типы потребителю Хранить скомпилированный JavaScript вместо outDir Автоматически исправлять ошибки

Вопрос 8 из 30

Почему удаление dist без tsbuildinfo может дать странную 'актуальную' сборку?

rm -rf packages/domain/dist
# build metadata осталось в другом месте

TypeScript хранит dist в памяти навсегда Кэш может считать входы неизменными Проблема возможна только на Windows composite запрещает clean rm не удаляет declaration

Вопрос 9 из 30

Как кэшировать tsc -b в CI?

Один общий кэш навсегда По размеру package.json По lockfile, версии TS, tsconfig и исходникам проекта Только по названию ветки Кэшировать node_modules без lockfile

Вопрос 10 из 30

Когда полная чистая сборка всё ещё нужна?

Только если нет tests После каждого сохранения локально Никогда после включения incremental Перед выпуском и периодически для проверки кэша Только для JavaScript-файлов

Вопрос 11 из 30

Почему импорт src внутреннего workspace-пакета опасен?

import { User } from "../../domain/src/model";

Импорт обходит публичный вход и граф references Такой импорт автоматически становится peer dependency Относительные импорты всегда запрещены TypeScript не умеет читать соседние файлы Исходный тип User выполняется в runtime

Вопрос 12 из 30

Как shared-пакет превращается в свалку?

@repo/shared
  date.ts
  user.ts
  db.ts
  ui.ts
  server.ts

Workspace запрещает больше трёх модулей Он смешивает роли, связывает слои и порождает циклы shared нельзя публиковать TypeScript требует default export В пакете слишком короткие имена файлов

Вопрос 13 из 30

Что даёт exports в package.json общего пакета?

{
  "exports": {
    ".": "./dist/index.js",
    "./testing": "./dist/testing.js"
  }
}

Делает все exports type-only Ограничивает и документирует публичные точки входа Заменяет references Копирует исходники в каждый пакет Автоматически запрещает TypeScript-циклы

Вопрос 14 из 30

Где размещать тип, используемый клиентом и сервером?

В глобальном namespace В UI-компоненте В независимом пакете протокола или схем В корневом index.ts всего репозитория В серверной сущности с методами ORM

Вопрос 15 из 30

Когда небольшое дублирование лучше общего пакета?

Никогда: одинаковые два поля требуют shared Когда тип имеет менее десяти строк Всегда для любых DTO Только если отключён strict Когда совпадение случайно, а причины изменений разные

Вопрос 16 из 30

Что не так с этим графом?

// domain imports infra for DatabaseClient
// infra imports domain for User

TypeScript запрещает любые два импорта Цикл решается изменением порядка references User нельзя импортировать в infra Абстракция зависимости оказалась не на той стороне границы DatabaseClient должен быть global

Вопрос 17 из 30

Почему paths на packages/*/src может обойти project references?

{
  "paths": { "@repo/*": ["packages/*/src"] }
}

Это влияет только на runtime Wildcard запрещён в monorepo Исходники всегда предпочтительнее d.ts без последствий Резолвятся исходники вместо декларационной точки пакета paths автоматически создаёт reference

Вопрос 18 из 30

Как статически запретить import из infra в domain?

// desired: domain -> no infra

Добавить noImplicitAny Спрятать import в function Положиться только на имена каталогов Использовать private у классов Отдельный tsconfig плюс правила или тесты импортов

Вопрос 19 из 30

Как относиться к циклу type-only между пакетами?

Он не добавляет runtime-ребро Он автоматически разрывается tsc -b Он возможен только через interface Он безопасен, если все импорты помечены как type Он выполняется раньше value imports

Вопрос 20 из 30

Как проверить изоляцию пакета?

Собрать пакет отдельно с dependencies и consumer-fixture Добавить все workspace в dependencies Проверить один относительный import Удалить declaration Запустить только корневой editor

Вопрос 21 из 30

Что должен подтвердить тест сборки domain-проекта с composite?

// domain/tsconfig.json
// { "compilerOptions": { "composite": true, "declaration": true } }

composite автоматически публикует пакет в npm Ссылки проектов устраняют любые циклы Зависимый проект получает доступ ко всем приватным файлам domain tsc -b всегда выполняет runtime-тесты Создаёт декларации для зависимых проектов без импорта исходников

Вопрос 22 из 30

Какой отрицательный пример защищает направление зависимостей?

// domain consumer
import type { SqlPool } from "@repo/infra/internal";

Импорт доменного UserId в app Использование публичного domain API Запрещённый импорт SqlPool из domain-пакета Сборка infra, зависящего от domain Runtime-тест репозитория

Вопрос 23 из 30

Почему успешный tsc -b не доказывает, что workspace-пакеты работают после публикации?

// локально import { x } from "@repo/domain" может разрешаться через paths

Локальные paths скрывают ошибки exports и состава пакета tsc -b не проверяет типы Project references работают только в браузере Публикация удаляет все declaration-файлы composite меняет ESM на CommonJS

Вопрос 24 из 30

Инкрементальная сборка прошла, а чистая упала. Какой тест добавить в CI?

Периодическая clean-сборка без dist и tsbuildinfo Проверку одного leaf-пакета Сравнение размера кэша Отключение declaration Только повторный tsc -b без изменений

Вопрос 25 из 30

Какой набор проверок лучше защищает монорепозиторий?

Сборка с нуля, инкрементальная и границы импортов Только root tsc без references Только unit-тесты приложений Только линтер имён пакетов Только кэширование node_modules

Вопрос 26 из 30

Какой публичный API общего пакета меньше всего связывает приложения?

// package exports: ".", "./testing", "./errors"

Deep imports в src каждого workspace Экспорт конфигурации сборщика вместе с доменными типами Корневой export * из всех пакетов Один тип SharedAnything = any Небольшие entry points по назначению вместо общего barrel

Вопрос 27 из 30

Что здесь нарушает границу domain-пакета?

export interface DomainApi {
  findUser(id: UserId): Promise<UserSummary | undefined>;
  sqlConnection: InternalPool;
  buildCachePath: string;
}

Тип UserSummary Публичные свойства sqlConnection и buildCachePath Метод findUser(id: UserId) Readonly-модификатор результата Размеченная ошибка not_found

Вопрос 28 из 30

Два пакета начали ссылаться друг на друга после выделения общего типа. Как лучше исправить граф?

// app -> domain -> shared
// infra -> domain -> shared

Импортировать исходники относительным путём Вынести контракт ниже или развернуть зависимость Скрыть цикл через any Добавить взаимные references Отключить composite у одного пакета

Вопрос 29 из 30

Как проверить выпуск нескольких workspace-пакетов?

Сравнить workspace-версии как строки Проверить симлинки node_modules Запустить только приложение из монорепозитория Упаковать пакеты и установить в чистый consumer без paths Открыть declarationMap в редакторе

Вопрос 30 из 30

Какой симптом говорит, что paths размыли архитектурные границы?

Общие типы вынесены в shared Используется tsc -b Каждый пакет имеет tsconfig Есть отдельный каталог dist Импорт internal-файла обходит публичный пакет

Ответьте на все 30 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу