谨慎使用 --outFile

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

2018-11-4 6:43

谨慎使用 --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

评论区