Инструменты разработки: от исходника до запуска

Оглавление · TypeScript · Команды проверок

Задача: понять, какой инструмент работает с текстом, типами, зависимостями или исполняемой программой. Нужны модули JS/TS и опыт запуска проекта.

Несколько независимых путей

flowchart TD
  Source["Исходный текст"] --> Parse["Парсинг и AST"]
  Parse --> Types["Typecheck: правила типов"]
  Parse --> Lint["Линтер: включённые правила"]
  Source --> Format["Форматтер: запись текста"]
  Parse --> Transform["Преобразование и сборка"]
  Transform --> Artifact["Артефакт приложения"]
  Artifact --> Run["Запуск в нужной среде"]
  Run --> Contract["Runtime-вход и поведение"]

Это схема ответственности, не обязательный порядок процессов каждого сборщика. AST представляет синтаксическую структуру. Проверка типов исследует код по своей модели; выполнение получает реальные значения и взаимодействует с источниками. Один зелёный этап не подтверждает остальные.

noEmit запрещает выпуск файлов компилятором: TypeScript может проверять типы, пока другой инструмент преобразует TS/JSX. TypeScript noEmit. Node 24 умеет удалять поддерживаемые типовые аннотации при запуске TS, но не проверяет типы, не читает tsconfig и не исполняет TSX этим механизмом. Type stripping Node 24. Это объясняет временные .mts из учебника; не заменяет сборку React/Next.

Что означает команда в нашем проекте

Проверяйте package.json и scripts пакета, а не выводите эффект по слову build. Contracts экспортирует dist; UIKit экспортирует исходники, которые обрабатывает приложение-потребитель. Корневой pnpm -r build учитывает зависимости workspace, но сам не знает бизнес-смысла каждого script.

Production-образы собираются в CI. Локальная целевая сборка docs допустима и не требует CMS; полная сборка web — другой сценарий из проверок.

Зависимости и разрешение модулей

package.json задаёт зависимости и команды, lockfile фиксирует разрешённый набор. Установка workspace — pnpm install --frozen-lockfile; несовпадение lockfile должно быть разобрано, а не исправлено его удалением ради успешной установки. pnpm install.

workspace:* связывает локальные пакеты. exports задаёт публичные входы пакета; import type нужен компилятору и не создаёт исполняемую зависимость. @/ в приложении задаётся конфигурацией; обычный Node не обязан понимать такой alias. Не проверяйте работу production-экспорта одним успешным импортом исходника.

Jest проекта явно направляет @atmanki/contracts на src и заменяет server-only тестовым shim. Это удобно для серверных тестов, но не проверяет наличие dist в релизе. Jest config.

Strapi — отдельный npm-проект с собственными версиями и lockfile: установка через npm ci в infra/strapi. Объединять его зависимости с workspace ради одинакового красивого дерева не требуется.

Редактор и воспроизводимая диагностика

Language server даёт переходы, подсказки и диагностику; он работает с выбранной версией и границами проекта. Сравните версию workspace TypeScript и версию, которую использует редактор. Сохранённый файл и CLI-проверка — общая точка сравнения.

Базовый TS-config включает strict; конфигурации приложений задают свой module resolution и generated types. Docs typecheck сначала запускает next typegen, затем tsc --noEmit. Не переносите отдельные compiler flags из учебной пробы в production-конфигурацию без разбора их смысла.

Sourcemap связывает преобразованный код с исходником. Breakpoint полезен, когда известны процесс и версия артефакта; строка TS в редакторе не доказывает, что именно она загружена браузером. Stack trace и локальные значения проверяют выбранный сценарий.

Браузер и изолированный компонент

Network показывает запросы, статусы и размеры; Elements — текущий DOM; computed styles — итог каскада. Console, storage и профилировщик отвечают на другие вопросы. DOM после JS не равен исходному HTML ответа: это важно для SSR/SSG.

Storybook проверяет компонент на заданных props и окружении. Dev-сайт проверяет интеграцию с роутером и CMS. Обновление dev-сервера облегчает цикл правки, но не является публикацией production. Happy-dom полезен для ограниченных DOM-проб; он не подтверждает реальную геометрию, поведение всех браузеров и screen reader.

Практика

Для одного изменения составьте цепочку: исходник → типы → преобразование → публичный экспорт → запуск → наблюдаемое поведение. Укажите, какой script даёт каждое свидетельство и чего он не проверяет.

Проследите import contracts в Jest и в приложении, затем сравните build UIKit и Storybook. Продолжите в лаборатории проверок, где ошибка каждого вида наблюдается отдельно.