TS TypeScript · 25 вопросов · ~70 мин · ⏱ Таймер 10:00 · Средний ·

Модули и разрешение импортов

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

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

⏱ --:--

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

Вопрос 1 из 25

Что делает type-only import?

import type { User } from "./model.js";
const current: User = { id: "u1" };

Загружает модуль дважды Разрешает использовать User как значение Отключает проверку экспорта Преобразует User в класс Импорт существует лишь для типов, не для runtime

Вопрос 2 из 25

Почему этот импорт требует обычной формы, а не import type?

import { Status } from "./status.js";
console.log(Status.Ready);

Все enums существуют только в типах Расширение .js превращает импорт в типовой console.log принимает только type imports Status используется как runtime-значение Обычный import нужен только default export

Вопрос 3 из 25

В показанном фрагменте что делает export type?

export type { User, UserId } from "./model.js";

Переэкспортирует только типовые имена Удаляет типы из исходного модуля Создаёт namespace Экспортирует значения как undefined Разрешает импорт без пути

Вопрос 4 из 25

Почему barrel-файл export * может создать неожиданную runtime-зависимость?

Barrel запрещает circular imports Он удаляет side effects Он может переэкспортировать неожиданные runtime-значения export * всегда выполняет tree shaking Все exports становятся type-only

Вопрос 5 из 25

Когда default export ухудшает сопровождение?

Когда включён strict Когда используется ESM Когда импортирующие сами выбирают имя Когда модуль один Когда экспортируется функция

Вопрос 6 из 25

Почему импорт ./user может вести себя иначе в NodeNext и bundler resolution?

import { user } from "./user";

NodeNext не поддерживает ESM moduleResolution меняет тип user Разницы нет ни при каких условиях Bundler всегда запрещает relative imports Режимы повторяют разные правила runtime и расширений

Вопрос 7 из 25

Что означает package.json exports для TypeScript?

{
  "exports": {
    ".": { "types": "./dist/index.d.ts", "import": "./dist/index.js" }
  }
}

Карту публичных путей к типам и значениям Команду копирования при npm publish Автоматическую генерацию declaration Только настройку браузера Список всех внутренних файлов пакета

Вопрос 8 из 25

Почему baseUrl/paths не переписывают runtime-import сами по себе?

{
  "compilerOptions": { "paths": { "@app/*": ["src/*"] } }
}

paths работает только с type imports Они помогают TypeScript разрешать путь tsc всегда заменяет @app на относительный путь paths устанавливает npm-пакет Alias существует только в source maps

Вопрос 9 из 25

Как выбрать moduleResolution?

Всегда classic По числу импортов По фактической среде загрузки По версии операционной системы Самое короткое название

Вопрос 10 из 25

Как расследовать, почему выбран не тот declaration-файл?

Запустить tsc --traceResolution и изучить путь Проверить только имя пакета Удалить все типы Добавить as any к импорту Отключить moduleResolution

Вопрос 11 из 25

Что делает paths в этом примере?

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": { "@core/*": ["src/core/*"] }
  }
}

Публикует пакет @core в npm Делает все core-модули global Связывает типовой импорт @core/x с файлами src/core/x Создаёт symlink во время выполнения Перемещает файлы в dist/core

Вопрос 12 из 25

Почему alias на внутренний каталог может нарушить архитектуру?

import { secret } from "@app/internal/cache";

Aliases всегда медленнее относительных путей Внутренние файлы автоматически публикуются Импорт станет type-only TypeScript запретит tree shaking Alias позволяет обходить публичную границу модуля

Вопрос 13 из 25

Как package imports (#core/*) отличается от одного tsconfig paths?

// package.json
{ "imports": { "#core/*": "./dist/core/*.js" } }

Он публикует под-путь внешним пакетам Он заменяет exports Его понимает поддерживающий runtime Node.js Он загружает исходные .ts без loader Он работает только внутри TypeScript

Вопрос 14 из 25

Когда относительные импорты лучше alias?

Всегда, независимо от глубины Только для JSON Только в тестах Никогда: ../ запрещён Для близких файлов небольшого компонента

Вопрос 15 из 25

Что проверить перед сменой alias?

Только npm install Одинаковое разрешение alias всеми инструментами Только редактор Только один production-файл Только source map

Вопрос 16 из 25

Какой риск в цикле модулей?

// a.ts
import { b } from "./b.js";
export const a = b + 1;
// b.ts
import { a } from "./a.js";
export const b = a + 1;

TypeScript всегда запрещает циклы Оба значения автоматически станут 2 Модуль может прочитать ещё не инициализированный binding Импорты выполняются параллельно без порядка Цикл влияет только на типы

Вопрос 17 из 25

Почему type-only cycle часто менее опасен?

// a.ts
import type { B } from "./b.js";
export type A = { b: B };

Цикл автоматически объединяет типы После стирания типов ребро выполнения исчезает Type-only импорт создаёт lazy require Он всё равно всегда вызывает код модуля Type imports выполняются раньше обычных

Вопрос 18 из 25

Как разорвать value-cycle между сервисами?

// UserService импортирует AuditService,
// AuditService импортирует UserService.

Заменить оба импорта на any Включить skipLibCheck Вынести контракт или внедрить зависимость Добавить ещё один barrel Поменять порядок строк import

Вопрос 19 из 25

Почему barrel-файлы затрудняют поиск циклов?

Они скрывают источник и втягивают лишние value-экспорты export * запрещает ESM Циклы возможны только через index.ts Редактор не показывает импорты Barrel удаляет все типы

Вопрос 20 из 25

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

Добавить as const к imports Полагаться только на успешный tsc Считать любой cycle безопасным Запустить formatter Анализ графа, холодный запуск и правила направлений

Вопрос 21 из 25

Что должен подтвердить тест с import type при включённом verbatimModuleSyntax?

import type { User } from "./model.js";
export function label(user: User) { return user.id; }

Типовой импорт не остаётся runtime-зависимостью в сгенерированном модуле import type разрешает использовать значение конструктора Компилятор копирует декларацию в JavaScript Импортированный тип становится глобальной переменной Файл автоматически переводится в CommonJS

Вопрос 22 из 25

Какой отрицательный тест полезен для package exports?

// consumer.ts
import { internalHelper } from "pkg/dist/internal.js";

Импортировать публичную точку входа Открыть исходный файл напрямую в редакторе Добавить path alias, обходящий exports Проверить локальный относительный импорт внутри пакета Импорт закрытого пути должен дать ошибку потребителю

Вопрос 23 из 25

Почему тест path alias должен запускаться и после сборки?

Runtime всегда читает tsconfig автоматически Alias действует только для CSS-файлов tsc знает paths, а runtime может не знать После сборки TypeScript повторно проверяет сеть paths меняет типы всех экспортов на any

Вопрос 24 из 25

После замены обычного импорта на import type исчез цикл в runtime. Как это проверить?

Переименовать оба файла Проверить итоговый граф импортов и запуск инициализации Проверить только, что редактор не подчёркивает строку Отключить isolatedModules Сравнить длину имени импортируемого типа

Вопрос 25 из 25

Какой тест лучше защищает смену moduleResolution с node на nodenext?

Сборка с noResolve Проверка только синтаксиса интерфейса Снимок списка исходных файлов Один файл без импортов Consumer с расширениями, exports и type-only imports

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

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

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

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