谨慎使用 --outFile
谨慎使用 --outFile 由于以下几点原因,你应该谨慎使用 --outFile 选项: 运行时的错误; 快速编译; 全局作用域; 难以分析; 难以扩展; _references; 代码重用; 多目标; 单独编译; 运行时的错误 如果你的代码依赖于上文中的 JavaScript,你可能会在运行时得到错误: 类的继承在运行时中断。 有如下 foo.ts...
谨慎使用 --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
。