当我们在开发维护一些工具类项目的时候，随着功能的丰富以及维护人员的变更，会导致代码的可持续维护性下降，因此需要一些其他工具来帮我们提高代码质量，减少一些不必要的错误。本篇我们来介绍使用TS来做一些事情。
什么是TS
TypeScript 是微软开发一款开源的编程语言，本质上是向 JavaScript 增加静态类型系统。它是 JavaScript 的超集，所有现有的 JavaScript 都可以不加改变就在其中使用。它是为大型软件开发而设计的，它最终编译产生 JavaScript，所以可以运行在浏览器、Node.js 等等的运行时环境。
TS能做什么
首先TS的定位是静态类型语言，而不是类型检查器（对比flow）。
从开发工具提供的能力看也不仅仅是类型检查，很直观的就是Intellisense over Compilation Error，当一段代码有问题（比如少写了字母）时，写完马上就会有红色波浪线提示，而不是等到编译的时候才告诉你哪一行有问题。
因此使用TS提供的类型系统+静态分析检查+智能感知/提示，使大规模的应用代码质量更高，运行时bug更少，更方便维护。
对比js有哪些优势
- 开发效率
虽然需要多写一些类型定义代码，但TS在WebStorm等IDE下可以做到智能提示，智能感知bug，同时我们项目常用的一些第三方类库框架都有TS类型声明（@types管理），我们也可以给那些没有TS类型声明的稳定模块写声明文件，这在团队协作项目中可以提升整体的开发效率。
- 可维护性
长期迭代维护的项目开发和维护的成员会有很多，人员的不稳定性和团队成员水平的差异的差异性，以及软件本身具有熵的特质，导致长期迭代维护的项目总会遇到可维护性逐渐降低的问题。而有了强类型约束和静态检查，以及智能IDE的帮助下，可以降低软件腐化的速度，提升可维护性。并且如果在重构代码时，强类型和静态类型检查会帮上大忙，一定程度上减少重构代价。（大家开发维护起来更安全、放心）。
- 线上运行质量
我们现在的工具类项目很多bug都是由于一些调用方和被调用方的数据格式不匹配引起的。TS可以在编译期进行静态检查，可以在编写调试代码时就发现这些问题，并且IDE可以智能纠错，编码时就能提前感知bug的存在，我们的线上运行时质量会更为稳定可控。
Flow、babel、tsc
- 类型检查
flow用来做类型检查，比如vue就是用的flow，但是flow也有很多问题：
- 无用的错误信息
比如 Incompatible instantiation for T， T 是一个类型变量，但是你并不能迅速找到这个错误在哪里。
2.运行困难
运行 Flow是需要一定成本的。对于Mac 用户来说非常幸运，通过 homebrew 可以安装预制的二进制包。但如果你需要自己编译它，你就先得建立一套 OCaml 开发环境。
- 代码处理
babel相比于tsc，首先定位是不同的，babel是一种js预处理工具，理论上说完全可以实现对ts的预处理，但是tsc对ts处理会更加精细。当然tsc 的功能没有 babel 多，扩展性也没有 babel 强。
项目的应用
我们的开源脚手架builder-webpack4已经实践了几个月了，为了更好的维护，我们决定迁移到ts。这中间踩了一些坑，但也积累了一些经验。
- tsconfig配置
ts配置文件有很多配置项，但是对于我们开发node工具来说其实用到的并不多，我们只需要关注模块化，编译路径和输出路径即可。
关于模块化，我们希望输出的是commonjs规范的，至于最终是es5/es6或是其他，因人而异，我们需要配置的就是：
"compilerOptions": {
"module": "commonjs",
"esModuleInterop": true,
"target": "es5",
"moduleResolution": "node"
}
编译路径和输出路径，这里跟webpack类似，当然这里的编译路径是指定tsc编译哪些目录下的ts文件，否则编译会因为内容太多而报错。
"compilerOptions": {
"outDir": "lib" //输出路径
},
//编译目录
"include": [
"src/**/*"
],
当然我们还可能会指定types的路径
"paths": {
"*": [
"node_modules/*",
"src/types/*"
]
}
- npm包的types
对于多数的npm包来说都可以通过安装@types/xxx来解决，比如node我们就可以安装@types/node，当然也有一些@types并没有做管理，那就需要我们自己来写一下。举个例子，webpack处理html相关会用到一个插件“html-webpack-plugin”，它是作为一个模块来使用，那么只需要以下声明即可
declare module 'html-webpack-plugin';
当然你可能会用到某些UMD的包（既可以当模块又可以作为全局变量使用）：
declare namespace UMD{
//可以定义一些其他东西
}
- interface（接口）
比如我们有些方法需要修改一些参数，使用TypeScript 之后，把数据对应的 interface 改掉，然后重新编译一次，把编译失败的地方全部改掉就好了。
对于builder-webpack4来说很多方法的参数都较为复杂，比如我们生成构建配置文件的时候，webpack的配置老多了，自然是需要写个interface来控制，但是问题是如果别的模块调用这个方法又得重写一次？不用的，只要吧interface当作模块一样导出即可（当然你也可以把这些写到d.ts中，然后引入到对应的文件）。
export interface xxx{
[propName: string]: any
}
- 静态类型检查
当我们开始盲写代码的时候，总会不可避免的有些小失误，那么利用IDE配合ts提供的工具就可以帮我们提前发现一些问题；在编译调试中同样可以发现一些未触及的点。
我们在调用方法的时候就知道这个方法需要哪些参数，当然如果类型写错了就立马会有红色波浪线标注出来（格外的扎眼）。
- 代码质量的提升
作为一种弱类型语言，js开发一些大型/持续维护项目的时候，经常会让人体验什么是“开发一时爽，重构火葬场”（ts在Q你了）。
- 其他注意点
对于模块的导出
export default builderWebpack4;
这个玩意编译出来其实是这样子的
exports.default = builderWebpack4;
但是对于调用者来说并不能直接用，我们想要的是
module.exports = builderWebpack4;
所以源码中多加个指定就好了
module.exports = exports.default;
当然对于项目内部间模块调用是不需要的，tsc构建会生成相关的hack
var __importDefault = (this && this.__importDefault) || function (mod) {
return (mod && mod.__esModule) ? mod : { "default": mod };
};
Object.defineProperty(exports, "__esModule", { value: true });
var webpack_1 = __importDefault(require("webpack"));
什么时候需要用
- 大型项目
项目越大，越难以维护，因此对于多人写协作的大型项目有必要使用ts来提高代码质量。
- 持续维护的项目
对于一些长久运行的项目，既要保证它的稳定运行，又要保证项目交接便捷（可维护性），使用ts是目前来看最好选择。
- 工具类项目
使用nodejs/js写一些前端工具或者库的时候，同样是需要关注以上两点内容，而且工具类的项目影响范围较大，在开发维护中要更加谨慎，那么使用ts帮我们尽量减少一些低级错误是很有必要的。
写在最后
feflow的开源脚手架builder-webpack4已经切换为ts编写了，欢迎大家使用，如果有任何问题可以提交issue。
