谨慎使用 —outFile

    • 运行时的错误；
    • 快速编译；
    • 全局作用域；
    • 难以分析；
    • 难以扩展；
    • _references；
    • 代码重用；
    • 单独编译；

    如果你的代码依赖于上文中的 JavaScript，你可能会在运行时得到错误：

    • 类的继承在运行时中断。
      有如下 foo.ts：

    以及 bar.ts：

    1. class Bar extends Foo {}

    如果你没有按正确的顺序编译它（例如：tsc bar.ts foo.ts），虽然它能够被编译成功，但是会在运行时抛出 ReferenceError 的错误。

    • 模块拆分在运行时会失败。
      foo.ts：

    bar.ts：

    1. namespace App {
    2.   export const bar = foo + 456;

    与上文中一致，当你没有用正确的顺序编译它，它会在运行时将 NaN 赋值给 bar；

    快速编译

    如果你使用 —out 编译选项，而没有使用一些 hacks 时，单独的 .ts 文件是不会被编译成单独的 .js 文件。 —out 选项实际上使用了较慢的构建方式。

    全局作用域

    当然，你可以使用命名空间，但是它仍然在 window 上（如果你在浏览器中打开），命名空间仅仅是一个临时的解决方式。///<reference 也不例外，它会引入一个难以维护的全局上下文。

    如果你的公司有多个独立工作的团队，当有人决定尝试集成两个程序编写 app 时，则很可能存在命名冲突。

    我们希望提供更多代码分析工具。如果你提供调用链的依赖关系，这些将会变得简单。

    难以扩展

    实际上这是运行时的随机错误 + 编译时间时间慢 + 难以理解的代码的结果。

    _references.ts

    它并没有被 tsconfig.json 支持：Comment，你需要手动对文件排序。

    如果你想在另一个项目中重用存在隐式依赖关系的代码，如果没有错误提示，很难移植它。

    多目标

    单独编译

    文件无法被单独编译，如 a.ts：

    根据不同的 b.ts 的形式，它将有不同的输出：

    1. namespace M {
    2. }

    或者：

    因此 a.ts 不能被单独编译;

    —out 做的是一些构建工具的工作，这些构建工具也可以受益于外部模块所提供的依赖，因此如果你愿意，我们推荐你使用外部模块，让构建工具创建单文件的 .js。