Это плохая идея для вас по следующим причинам:
- Ошибки во время выполнения
- Скорость компиляции
- Глобальная область видимости
- Трудно анализировать
- Трудно масштабировать
_references- Сложность переиспользования кода
- Переход между окружениями
- Невозможность изолированной компиляции
Если ваш код зависит от очерёдности, вы получите случайные ошибки во время выполнения.
- наследование классов может сломаться во время выполнения.
Рассмотрим foo.ts:
class Foo {
}и bar.ts:
class Bar extends Foo {
}Если вам не удалось скомпилировать их в определённом порядке, например в алфавитном порядке tsc bar.ts foo.ts код будет компилироваться нормально, но во время выполнения произойдет ошибка ReferenceError.
- разделение модуля может завершиться ошибкой во время выполнения.
Рассмотрим foo.ts:
module App {
export var foo = 123;
}и bar.ts:
module App {
export var bar = foo + 456;
}Если вам не удалось скомпилировать их в определённом порядке, например в алфавитном порядке tsc bar.ts foo.ts код будет компилироваться нормально, но молча завершится с ошибкой во время выполнения с bar, установленным на NaN.
Если вы используете --out, то отдельные файлы .ts нельзя сгенировать в отдельные файлы .js без ненужных хаков. --out по сути навязывает более медленную поэтапную сборку.
Кроме того, source maps позиционно чувствительны и сжимаются на повторы серий символов, поэтому большая часть source maps должна быть перестроенна при перекомпиляции, если вы используете source maps (что вам крайне рекомендуется!). При высоких значениях от 10 секунд до 100 секунд на тысячу строк кода это будет приводить к замедлению.
Конечно, вы можете использовать пространства имен, но оно все еще находится в window, если вы запустите его в браузере. Пространства имен - это просто ненужный обходной путь. Также комментарии /// <reference представляют глобальный контекст в вашем коде, который может быть трудно поддерживать.
Кроме того, если в вашей компании несколько команд работают независимо, а затем кто-то решает попробовать интегрировать два независимо написанных приложения, существует высокая вероятность конфликта имен.
Мы хотим предоставить больше инструментов для анализа кода. Это будет проще, если вы предоставите нам цепочку зависимостей (неявно, на блюдечке, всего лишь используя внешние модули).
Кроме того, не только инструменты разработчика испытывают трудности с пониманием кода. Следующему разработчику нужно понять большую часть кодовой базы, прежде чем он начнет понимать, откуда что на самом деле импортируется. Использование внутренних модулей также затрудняет анализ кода изолированно, например на github.
На самом деле это просто результат случайных ошибок во времени выполнения + более медленное время компиляции + трудности с пониманием чужого кода.
Не поддерживается tsconfig.json: microsoft/TypeScript#2472 (comment) Вам придется вручную отсортировать массив файлов.
Если вы хотите повторно использовать часть своего кода в другом проекте со всем этим неявным управлением зависимостями, будет сложно перенести его без потенциальных ошибок во времени выполнения.
Также, если вы решите повторно использовать свой браузерный код в чем-то вроде nodejs (например, для тестирования API), вам нужно будет перенести его в модульную систему или придумать уродливые хаки, чтобы сделать global из nodejs вашей новой глобальной областью видимости (а именно window).
Файлы не могут быть скомпилированы изолированно. Например. рассмотрим a.ts:
module M {
var s = t;
}Вывод будет разным в зависимости от того, есть ли b.ts следующего содержания:
module M {
export var t = 5;
}или
var t = 5;Итак, a.ts не может быть скомпилирован изолированно.
--out - это работа инструмента сборки. И инструмент сборки может извлечь выгоду используя информацию о зависимостях, предоставляемых внешними модулями. Поэтому мы рекомендуем вам использовать внешние модули, а затем позволить инструменту сборки создать для вас один файл .js, если вы того пожелаете.
https://twitter.com/nycdotnet/status/613705850574778368
