为什么大厂的前端开源库（组件库）都使用 Typescript 而不是 JavaScript？

类型是很好的注释，对于很多api来说，暴露出类型就至少有了3成的文档了。

js的时代是需要借助jsdoc去手动标注，尽管如此他的表现力还是会差很多。

尤其是泛型的引入，对于需要大量依赖异步/回调的库来说，降低了相当大的心智负担，这一点在回调函数泛滥的项目中有奇效。

ts的enum和字面量做的挺不错，可以将js中的magic variable都转化成enum或者一连串的or表达。

同时ts的type alias也是一个有趣的点，能有效地细化你的类型表达，例如

type tInt = number;
type tFloat = number;
type tDouble = number;
type tJsonListStr = string; // 该字符串json.parse 反序列化后可以得到一个Array

这样约定一遍后在很多地方可以规避很多不得不说的内容，还挺有用的...

另外如果写后端跟db打交道的话，简单的ORM操作（Mongo这种太复杂的先不表，就说sequelize或者typeORM这种），都可以获得比较好的使用体验。

基本上上万行级别的项目，用ts的收益基本是绝对大于付出的成本的。

我做过的几个很舒适的应用场景，share一下：

1. 使用装饰器（也可能需要自己写一点），结合一些插件做ts的AST解析，可以做到自动导出swagger api文档，基本准确。
2. 使用ts重构过网易云信的demo，基本上是上万行，把jquery的项目改成了vue的，从读代码到功能重构完大概花了不到两星期，如果没有ts的良好定义的话基本上不太可能，大部分时间都会花在来回查文档上。
3. 事件类型标注，可以让pub/sub事件时约定形参列表，这一点对大量进行全局事件通信的应用有非常显著的开发体验提升（这个可以看一下eventemitter3的代码）。

说到底，非常重要的一点就是，需要大量多人协作/长期迭代/接口数量庞大的项目，可以借助类型系统解放查找数据结构和类型的时间，同时也减少文档编写的工作量, 很多情况下在interface这一层讲清楚这个是干什么，使用者点一下看就知道了。这一点在使用G2这种图形库的时候感受很深，看类型定义比翻文档要简明直白很多...

几个不方便的地方：

1. 不熟悉/长时间不写的话，对于编写d.ts，以及类似导出库的类型/变量对齐，甚至扩展类这种会写的非常痛苦，新人可能加个全局变量都会崩溃，这个最好的方法就是参考一些其他的开源库的做法，多差资料。
2. ts的迭代比较快，有些feature的加入会让原来的编译不通过，可以锁版本或者根据新的feature改掉
3. tsconfig.json配置好多，不懂怎么配置，这个也没办法，只能慢慢学...
4. 能获取到多少类型支持有时候取决于库作者对内部类型的暴露程度，有时候能看不能用很着急...这时候我会选择自己fork一份出来放在私有npm上，再把版本锁住，提不提pr看心情...

总之，如果团队中没有熟悉的人/项目时间紧/项目小/项目用完就扔/项目下游没有编辑器级别的变量跳转和类型支持(例如express写html模板)，就不建议用ts了。

另外熟悉ts非常有助于提高对于dart/kt/swift等语言的接受度，对于有志于做跨端应用，使用flutter或为其他技术栈做准备的人，基本上类型系统是迈不过去的侃。ts玩的溜，有时候你会发现很多语言的类型系统表现力甚至还不如ts强2333