# 谨慎使用 --outFile

由于以下几点原因，你应该谨慎使用 --outFile 选项：

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

# 运行时的错误

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

• 类的继承在运行时中断。

有如下 foo.ts：

class Foo {}

以及 bar.ts：

class Bar extends Foo {}

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

• 模块拆分在运行时会失败。

foo.ts：

namespace App {
  export const foo = 123;
}

bar.ts：

namespace App {
  export const bar = foo + 456;
}

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

# 快速编译

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

此外，由于 source map 基于长度编码，且对位置信息敏感，因此，大部分 source map 都会在编译时重新构建（如果你使用 source map）。

# 全局作用域

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

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

# 难以分析

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

# 难以扩展

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

# _references.ts

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

# 代码重用

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

# 多目标

如果你想在 nodejs 之类的环境下重用在浏览器中的代码（如：testing APIS），你将不得不将其转换到新的模块系统或者使用不好的 hacks，让 nodejs 的 global 成为你的新的全局变量（如：window）。

# 单独编译

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

namespace M {
  var s = t;
}

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

namespace M {
  export var t = 5;
}

或者：

var t = 5;

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

# 总结

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