outFile caution

Це погана ідея для вас через такі причини:

• Помилки виконання

• Швидка компіляція

• Глобальний масштаб

• Важко аналізувати

• Важко масштабувати

• _references

• Повторне використання коду

• Кілька цілей

• Ізольована компіляція

Runtime Errors

Якщо ваш код залежить від будь-якої форми впорядкування js, ви отримаєте випадкові помилки під час виконання.

• успадкування класу може бути порушено під час виконання.

Розглянемо foo.ts:

class Foo {
    
}

and a bar.ts:

class Bar extends Foo {
    
}

Якщо вам не вдається скомпілювати його в правильному порядку, Напр. можливо, за алфавітом tsc bar.ts foo.ts код компілюватиметься добре, але під час виконання виникне помилка з ReferenceError.

• розбиття модулів може виникнути збій під час виконання.

Розглянемо foo.ts:

module App {
    export var foo = 123;
}

And bar.ts:

module App {
    export var bar = foo + 456;
}

Якщо вам не вдається скомпілювати його в правильному порядку, напр. можливо, в алфавітному порядку tsc bar.ts foo.ts код скомпілюється добре, але мовчки зазнає помилки під час виконання з bar встановленим на NaN.

Fast compile

Якщо ви використовуєте --out, то окремі файли .ts не можна кодувати в окремі файли .js без непотрібних хаків. --out по суті змушує повільніше поступове збирання.

Крім того, source maps є позиційно чутливими та закодовані за довжиною циклу, тому більшу частину карти потрібно перекомпілювати заново, якщо ви використовуєте source maps (що ви повинні!). При високих показниках від 10 до 100 секунд він буде повільним.

Global Scope

Звісно, ви можете використовувати простори імен, але він все ще знаходиться у window, якщо ви запускаєте його у браузері. Простори імен — це лише непотрібний обхідний шлях. Крім того, коментарі /// <reference вводять глобальний контекст у ваш код, який може бути важко підтримувати.

Крім того, якщо у вашій компанії є кілька команд, які працюють незалежно, а потім хтось вирішує спробувати інтегрувати дві незалежно написані програми, висока ймовірність конфлікту імен.

Hard to analyze

Ми хочемо надати більше інструментів аналізу коду. Це буде легше, якщо ви надасте нам ланцюжок залежностей (неявно на срібному блюді за допомогою зовнішніх модулів).

Крім того, не тільки dev tools допомогають зрозуміти код. Колт людині потрібно зрозуміти багато кодової бази, перш ніж вони почнуть розуміти, звідки імпортуються речі. Використання внутрішніх модулів також ускладнює перегляд окремого коду, наприклад, на github.

Hard to scale

Насправді просто результат випадкових помилок виконання + все повільніший час компіляції + труднощі з розумінням чужого коду.

_references.ts

Не підтримується tsconfig.json: https://github.com/Microsoft/TypeScript/issues/2472#issuecomment-85330803 Вам доведеться вручну сортувати масив files.

Code reuse

Якщо ви хочете повторно використати частину свого коду в іншому проекті з усім цим неявним керуванням залежностями, буде важко перенести його без потенційних помилок виконання.

Multiple Targets

Крім того, якщо ви вирішите повторно використовувати свій код браузера в чомусь на кшталт nodejs (наприклад, для тестування API), вам потрібно буде перенести його на модульну систему або придумати потворні хаки, щоб зробити nodejs global вашим новим глобальним scope (тобто window).

Isolated Compile

Файли не можуть бути скомпільовані окремо. Наприклад розглянути a.ts:

module M {
  var s = t;
}

Матиме різний вихід залежно від того, чи існує b.ts форми:

module M {
  export var t = 5;
}

or

var t = 5;

Отже, a.ts не можна скомпілювати ізольовано.

Summary

--out насправді є завданням якогось інструменту для збирання. І навіть такий інструмент збирання може отримати користь від згадок про залежності, наданих зовнішніми модулями. Тому ми рекомендуємо вам використовувати зовнішні модулі, а потім дозволити інструменту збірки створити для вас єдиний .js, якщо ви цього бажаєте.

https://twitter.com/nycdotnet/status/613705850574778368

Сигнал Bas