Правльная структура проектов на TypeScript

Рейтинг: 0Ответов: 0Опубликовано: 04.08.2025

Описание

Я работаю с TypeScript уже более 6 лет, но до сих пор не понял, как организовать структуру проекта так, чтобы она была универсальной.


Например, возьмем проект на Electron, который может включать NodeJS, Web API и WebWorkers API. У меня есть такой базовый проект:

В папке src находится все, что должно компилироваться в папку dist. Однако содержимое src делится на части по средам:

  • src/core — это набор модулей для ядра ESM, которые могут быть использованы в NodeJS, Web API или где угодно.
  • src/homepage — содержит HTML-страницу, ее стили и скрипты. Здесь работает Web API, но не работает Node.
  • src/index.ts — это точка входа, которая сейчас собирает страницу для Electron и запускает приложение.
  • src/workers (будет добавлен) — папка для скриптов, работающих с WebWorkers API, где не поддерживаются Node и Web API.

Теперь мне нужно описать все это в tsconfig.json, чтобы правильно указать среду для каждой папки.

{
    "compilerOptions": {
        "target": "ESNext",
        "lib": [ "ESNext", "DOM", "WebWorker" ],
        "module": "ESNext",
        "moduleResolution": "bundler",
        "outDir": "./dist",
        "declaration": true,
        "sourceMap": true,
        "strict": true,
        "esModuleInterop": true,
        "skipLibCheck": true,
        "allowJs": true,
        "forceConsistentCasingInFileNames": true,
    },
    "include": [ "./src/**/*" ]
}

Такой tsconfig.json вызывает ошибки. Например, в index.ts будут отображаться классы, не существующие в данной среде, например, HTMLHeadingElement. Если указать меньше библиотек, компиляция просто не произойдет, так как часть проекта не будет найдена.

Если использовать tsconfig в каждой папке, то до компиляции все будет работать, но во время компиляции будет использоваться только один из них.

Если собирать комплексный проект с references и "composite": true, то для каждого подпроекта придется указывать, что и куда компилировать. Но это один проект, а не несколько.

И это еще не учитывая версию языка, которая иногда может быть ESNext, иногда ES2022, а иногда ES2016.

Вопрос

Какую структуру, подход или алгоритм можно использовать, чтобы собирать универсальные проекты без проблем при переходе между ними?

Ответы

Ответов пока нет.