Привет @lazutkin. В настоящее время это не поддерживается, хотя я просто хочу связать эту проблему с # 2869, потому что она отчасти связана.

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

Я не думаю, что мы будем поддерживать конфигурацию интеграции / переопределения из нескольких tsconfig.json.

Несколько файлов tsconfig незаменимы для крупных корпоративных приложений.
Предложение: Каждый раз, когда tsc находит новый файл tsconfig в подкаталоге, tsc останавливается здесь и создает новый процесс tsc с собственным файлом tsconfig.

@Eisenspalter это похоже на задание драйвера сборки, что-то вроде grunt, gulp или msbuild.

@mhegazy Я согласен с @Eisenspalter, потому что мы оба говорим не о процессе сборки, а о процессе разработки, включая написание исходников, тестирование и другие действия, которые мы должны выполнить перед сборкой. На всех этих промежуточных этапах нам нужна поддержка со стороны typescript включая intellisense, проверку типов и т. Д. Более того, как я уже говорил ранее, для разных частей проекта мы хотели бы применить разные методы организации исходного кода (внешние и внутренние модули, отдельные выходной файл и т. д.), и здесь нам нужно переопределить некоторые параметры отдельным файлом tsconfig.

@mhegazy Почему закрылись? Пожалуйста, откройте снова.

сегодня у вас может быть несколько tsconfig, каждый из которых указывает на перекрывающийся набор файлов. так что один в srctsconfig.json, один в teststsconfig.json и т. д. компилятор / tools найдет файл, пройдя вверх по дереву каталогов, чтобы найти ближайший. так что вы можете иметь третий файл в корне, чтобы поймать все.

Все это работает сегодня в компиляторе и различных IDE. исходная проблема заключалась в том, чтобы разрешить файлу наследовать от другого. Я не думаю, что там достаточно ценности, чтобы гарантировать сложность.

По второму вопросу:

Каждый раз, когда tsc находит новый файл tsconfig в подкаталоге, tsc останавливается здесь и создает новый процесс tsc со своим собственным файлом tsconfig.

Как я упоминал ранее, tsconfig.json представляет собой однократный вызов tsc.js / tsc.exe, если вы хотите выполнить несколько вызовов, вам следует использовать драйвер сборки.

@lazutkin и @Eisenspalter отвечают на вопросы

@mhegazy
Не удалось заставить работать несколько файлов tsconfig.json. По крайней мере, с TypeScript 1.7.3 считывается только один файл tsconfig.json, который, как ожидается, находится в корневом каталоге (или родительском каталоге) проекта.

@Ziink, мой комментарий выше не касался нескольких tsconfigs в одном проекте. речь шла о нескольких проектах / каталогах, каждый с другим tsconfig. вот как устроен проект ts, см. https://github.com/Microsoft/TypeScript/tree/master/src , каждая папка в src имеет свой tsconfig.json

У меня есть проект, написанный на TypeScript, и я хочу работать с обоими:

1. браузер (скажем, файлы в /browser ) с ES5 / AMD и
2. nodejs (файлы в server ) с CommonJS и генераторами (и async / await в TS).

Есть несколько общих файлов, скажем, в папке ( /common ), и есть импорт из common в browser и server .
Как я могу добиться такой конфигурации с сохранением поддержки IDE, всех ошибок и т. Д.? Не уверен, что дискуссия ответила на мои сомнения.

@bartq В TS 1.8 я бы создал два файла tsconfig, один для браузера и один для сервера, и добавил /// ссылки в ваших файлах в обоих подпроектах к общим. попробуйте и дайте нам знать, относится ли это к сценарию или все еще есть недостающие части.

на самом деле я использую эти два файла tsconfig.json , WebStorm обнаруживает их и автоматически запускает компиляцию. Если быть точным, внутренний код импортирует некоторые классы из внешнего кода (вместо этого используется концепция common ), но все это работает нормально.

Наконец-то я получил решение.

моя структура приложения:
- приложение /- app / client / (мой исходный код на стороне клиента)- app / server / (исходный код на стороне моего сервера)- app / build / (где я генерирую js)- приложение / узлы-модули /- app / package.json- приложение / tsconfig.server.json- приложение / tsconfig.client.json

Содержимое tsconfig.server.json:
{"compilerOptions": {..., "outDir": _ "build / server" _},"exclude": ["node_modules", "client"]}

Содержимое tsconfig.client.json:
{"compilerOptions": {..., "outDir": "build / client"},"exclude": ["node_modules", "server"]}

Затем, когда я хочу скомпилировать исходный код сервера, я использую эту команду из корневого каталога приложения:

tsc --p tsconfig.server.json

И чтобы скомпилировать исходный код клиента, также из корневого каталога приложения:

tsc --p tsconfig.client.json

Чтобы запустить компиляцию клиента и сервера, я добавил команду в package.json:

"scripts": {..., "tsc": "tsc --p tsconfig.server.json && tsc --p tsconfig.client.json", ...}

Затем, чтобы скомпилировать и сервер, и клиент, я просто запускаю это из своего корневого каталога приложения:

npm run tsc

Надеюсь, этот комментарий может вам помочь :-)

Я не понимаю, в чем проблема. Почему мы не можем поддерживать конфиги с разными именами файлов? Больно создавать вложенные папки ТОЛЬКО для того, чтобы иметь другой файл tsconfig.

Вы можете. Аргумент --p может быть именем файла.

Однако разные имена файлов не будут работать с расширением компилятора машинописного текста Visual Studio (не говоря уже о CLI) из коробки. Единственный способ сделать это - поместить каждый tsconfig.json в фиктивный каталог и связать его с нужными вам наборами скриптов с помощью параметра files .

например

--src / цель / поиск / tsconfig.json
--src / цель / ядро ​​/ tsconfig.json
--src / цель / пользователи / tsconfig.json

target / search / tsconfig.json будет выглядеть примерно так:

{
  "compilerOptions": {
    "outFile": "../../../build/app/search.js"
  },
  "files": [
    "../../src/common",
    "../../src/search"
  ]
}

И остальные были бы похожи.

Это создаст 3 файла javascript, каждый со своей собственной конфигурацией файлов, объединенных в один.

Конечно, вы можете использовать другое решение для объединения / минимизации / упаковки, чем сам компилятор Typescript.

Просто компилятор Typescript действительно хорошо справляется с оптимизацией - это одно из самых больших преимуществ использования Typescript.

Итак, было бы неплохо, если бы один tsconfig.json мог поддерживать несколько конфигураций, просто изменив его на массив tsconfigs:

[
  {
    "compilerOptions": {
      "outFile": "../../build/search.js"
    },
    "files": [
      "src/common",
      "src/search"
    ],
    "compileOnSave": true
  },
  {
    "compilerOptions": {
      "outFile": "../../build/core.js"
    }
    "files": [
      "src/common",
      "src/core"
    ],
    "compileOnSave": true
  }
]

Это похоже на то, что запрашивается в более поздних комментариях к этой проблеме, хотя я согласен, исходная проблема была больше связана с наследованием и переопределением конфигураций.

@mhegazy @bartq Я не могу заставить его работать с помощью команды tsc .
У меня следующая структура каталогов

-- app/
-- app/server  -- here I want es6/commonjs
-- app/server/tsconfig.json
-- app/client    -- here I want es6/es6 
-- app/client/tsconfig.json
-- app/tsconfig.json

Тем не менее, когда я запускаю tsc только конфигурация из app/tsconfig.json , остальное игнорируется. Я пытаюсь заставить его работать в VSCode: /

@tomitrescak Я использую WebStorm, и он достаточно умен, чтобы найти ближайший tsconfig.json и использовать его при редактировании файла. Вероятно, не существует инструмента cmd, который поддерживает просмотр нескольких файлов tsconfig.json. Развернуть можно с помощью например сторожа FB.

Да, я бы хотел иметь что-то подобное в VS Code. Я запускаю компиляцию в терминале. Также работает. VS Code в любом случае правильно определяет ошибки.

Было бы здорово использовать несколько конфигураций. Я работаю над проектом React-Native, и в основном у меня есть две сборки, которые я хочу сделать:

1. скрипты моего проекта React-Native
2. скрипты, используемые в HTML для React-Native WebViews (диаграммы).

Наследование конфигурации было добавлено в TS 2.1 и должно быть доступно в typescript@next сегодня. см. https://github.com/Microsoft/TypeScript/issues/9876 для получения дополнительных сведений. Благодаря этому у вас может быть "главный" tsconfig.json и переопределить те, которые наследуют от него конфигурации. вам по-прежнему нужно создать несколько файлов tsconfig.json, но ваша IDE должна их подобрать.

У меня следующая структура каталогов:

├── examples
│   ├── files...
│   └── tsconfig.json
├── src
│   └──files...
└── tsconfig.json

Корень tsconfig.json имеет:

{
  "compilerOptions": {
    "target": "es2015",
    "module": "commonjs",
    "moduleResolution": "node",
    "outDir": "dist",
    "sourceMap": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "removeComments": false,
    "noImplicitAny": false,
    "declaration": true,
    "allowJs": false
  },
  "include": [
    "./src"
  ],
  "compileOnSave": false,
  "buildOnSave": false,
  "atom": { "rewriteTsconfig": false }
}

examples/tsconfig.json имеют то же значение, за исключением:

  "include": [
    "./hello-world"
  ],

Когда я делаю:

cd examples
tsc

Он компилирует:

├── examples
│   ├── dist
│   │   ├── examples
│   │   └── src
│   ├── files...
│   └── tsconfig.json
├── src
│   └──  files...
└── tsconfig.json

( dist неверно включает внешнюю папку src и компилируется как из корневой папки)

Не помогите (в examples/tsconfig.json ):

  "exclude": [
    "../src"
  ],

Что я делаю неправильно?

Я обнаружил проблему. Если в моем examples/hello-world/any-file*.ts этот импорт:

import { SomeClass } from '../../src';

Это создает описанную выше проблему. Следующий импорт работает должным образом:

import { SomeClass } from '../../';

Но почему директива машинописного текста include работает не так, как ожидалось?

Я не могу заставить это работать
Он настаивает на « Предупреждение: не удается найти родительский tsconfig.json», хотя у меня есть tsconfig.json в той же папке, не знаю, что с этим делать.

@zhukovka, пожалуйста, зарегистрируйте новую проблему с автономным воспроизведением, которое мы можем запустить локально

@RyanCavanaugh О. спасибо я разобрался
проблема воспроизводится только в том случае, если у меня есть один файл, открытый из тестовой папки (который не включает tsconfig.json), а второй файл открыт в папке 'src' (которая включает tsconfig.json)
а файл из тестовой папки импортирует файл из папки src. В этом случае файл из папки src не видит своего «родительского tsconfig.json»

@RyanCavanaugh , поддержка компиляции с несколькими разными tsconfig.json, похоже, по-прежнему является тем, что разработчики хотели бы иметь. В моих случаях обычно речь идет об изменении места расположения сгенерированных файлов вывода. Похоже, что если бы генерации кода можно было контролировать с помощью чего-то вроде существующего сопоставления paths позволяющего мне размещать мой сгенерированный код иначе, чем исходный, возможно, потребность в нескольких проектах уменьшилась бы.

Мой вариант использования состоит в том, что у меня есть большая устаревшая кодовая база, которая не может выдерживать более строгие правила проверки типов, и я хочу использовать ее в новой кодовой базе, в которой _действует_ строгие проверки, и я не могу скомпилировать устаревший код в библиотека, потому что у нее есть миллион случаев, когда она не импортирует все типы, необходимые для именования типов для ее экспорта (# 9944). Поэтому я хочу просто добавить устаревшую кодовую базу в новую кодовую базу, но скомпилированную в соответствии с более слабыми правилами. Это не может быть 2 разных этапа компиляции; когда компилятор работает с исходными файлами в определенном каталоге, он должен использовать более слабые правила.

Для меня вариант использования - это часть репо, которая запускается с использованием node и должна быть скомпилирована до модулей commonjs, в то время как другая часть должна быть скомпилирована в модули ES6, чтобы включить treehaking в ES6. Опыт не очень хорош, в моем случае много взлома с переменными окружения TS_NODE_PROJECT . Это определенно кажется чем-то, что могло бы чертовски запутать следующего человека, поддерживающего его, когда я, в конце концов, меняю проекты.

Я все еще хотел бы, чтобы это было решено. Это будет огромная победа для более крупных проектов, требующих разных файлов tsconfig.json для каждого модуля внутри проекта.

@Robinfr, что extends не решает для вас?

Это было так. Я узнал об этом после этого поста. Однако следует отметить, что это не сработало без установки include для файлов, которые k обычно не требуется, поскольку он проходит через webpack.

Оп 15 сен. 2017 9:24 schreef Китсон Келли [email protected] :

@Robinfr https://github.com/robinfr что делает расширяет функцию https://www.typescriptlang.org/docs/handbook/tsconfig-json.html#configuration-inheritance-with-extends не решить для вас?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это электронное письмо напрямую, просмотрите его на GitHub https://github.com/Microsoft/TypeScript/issues/3645#issuecomment-329703706 или отключите поток https://github.com/notifications/unsubscribe-auth/AD90FLZKcHMJeFU0osJroToToJawl .

Расширение @kitsonk работает хорошо, хотя, если я не делаю что-то не так, мне придется повторить определенные настройки (за исключением папок build и node_modules) в обоих конфигах. для меня самая большая проблема заключается в том, чтобы убедиться, что все мои инструменты знают, какой файл конфигурации является правильным (обычно с помощью чего-то вроде переменной среды TS_NODE_PROJECT . Другой - при открытии проекта с двумя tsconfigs в VS.code. Нет способа (насколько я знаю) указать VS, какой файл проекта использовать, и это означает, что для некоторых файлов ошибки не будут правильно подчеркнуты из-за различных настроек для этих файлов в соответствующем tsconfig (скажем, что-то например tsconfig.build.json).

@voy, могу я спросить, почему у вас другой tsconfig для сборки? Насколько я понял, VSCode использует ближайший файл tsconfig ( tsconfig.json ) к файлу, который вы редактируете. Единственная проблема, с которой я столкнулся до сих пор, заключается в том, что вам нужно иметь файл tsconfig в корне, прежде чем VSCode, похоже, вообще начнет использовать конфигурации ...

@Robinfr конечно. в том же репозитории у меня есть файлы, которые обрабатываются с помощью webpack и babel и используют модули ES6 для включения встряхивания дерева. другие файлы являются частью процесса сборки и выполняются с использованием node, поэтому импорт необходимо преобразовать в require. не уверен, как я могу это обойти.

@voy, разве бы у вас не было этих файлов в отдельной папке? Например, 1 папка для всех файлов Babel и webpack и 1 для файлов узлов. Тогда у вас может быть просто tsconfig.json для каждой из этих папок. Разве это не сработало бы для вас?

@Robinfr, это было бы идеально, но я думаю, что это не всегда возможно в реальном мире. например, мы хотим, чтобы все наши файлы конфигурации также были машинописными, скомпилированными и линкованными в соответствии с теми же правилами, что и вся кодовая база TypeScript, а некоторые файлы должны находиться в корне проекта. вы можете использовать символическую ссылку, но это иногда вызывает другие проблемы. вот почему я считаю, что что-то более гибкое было бы полезным.