前端工具类项目规范化-使用TS

当我们在开发维护一些工具类项目的时候，随着功能的丰富以及维护人员的变更，会导致代码的可持续维护性下降，因此需要一些其他工具来帮我们提高代码质量，减少一些不必要的错误。本篇我们来介绍使用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或是其他，因人而异，我们需要配置的就是：

代码语言：javascript复制

"compilerOptions": {
    "module": "commonjs",
    "esModuleInterop": true,
    "target": "es5",
    "moduleResolution": "node"
}

编译路径和输出路径，这里跟webpack类似，当然这里的编译路径是指定tsc编译哪些目录下的ts文件，否则编译会因为内容太多而报错。

代码语言：javascript复制

"compilerOptions": {
    "outDir": "lib" //输出路径
  },
  //编译目录
  "include": [
    "src/**/*"
  ],

当然我们还可能会指定types的路径

代码语言：javascript复制

"paths": {
      "*": [
        "node_modules/*",
        "src/types/*"
      ]
    }

npm包的types

对于多数的npm包来说都可以通过安装@types/xxx来解决，比如node我们就可以安装@types/node，当然也有一些@types并没有做管理，那就需要我们自己来写一下。举个例子，webpack处理html相关会用到一个插件“html-webpack-plugin”，它是作为一个模块来使用，那么只需要以下声明即可

代码语言：javascript复制

declare module 'html-webpack-plugin';

当然你可能会用到某些UMD的包（既可以当模块又可以作为全局变量使用）：

代码语言：javascript复制

declare namespace UMD{
 	//可以定义一些其他东西
}

interface（接口）

比如我们有些方法需要修改一些参数，使用TypeScript 之后，把数据对应的 interface 改掉，然后重新编译一次，把编译失败的地方全部改掉就好了。

对于builder-webpack4来说很多方法的参数都较为复杂，比如我们生成构建配置文件的时候，webpack的配置老多了，自然是需要写个interface来控制，但是问题是如果别的模块调用这个方法又得重写一次？不用的，只要吧interface当作模块一样导出即可（当然你也可以把这些写到d.ts中，然后引入到对应的文件）。

代码语言：javascript复制

export interface xxx{
    [propName: string]: any
}

静态类型检查

当我们开始盲写代码的时候，总会不可避免的有些小失误，那么利用IDE配合ts提供的工具就可以帮我们提前发现一些问题；在编译调试中同样可以发现一些未触及的点。

image

我们在调用方法的时候就知道这个方法需要哪些参数，当然如果类型写错了就立马会有红色波浪线标注出来（格外的扎眼）。

image

代码质量的提升

作为一种弱类型语言，js开发一些大型/持续维护项目的时候，经常会让人体验什么是“开发一时爽，重构火葬场”（ts在Q你了）。

其他注意点

对于模块的导出

代码语言：javascript复制

export default builderWebpack4;

这个玩意编译出来其实是这样子的

代码语言：javascript复制

exports.default = builderWebpack4;

但是对于调用者来说并不能直接用，我们想要的是

代码语言：javascript复制

module.exports = builderWebpack4;

所以源码中多加个指定就好了

代码语言：javascript复制

module.exports = exports.default;

当然对于项目内部间模块调用是不需要的，tsc构建会生成相关的hack

代码语言：javascript复制

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。

webpack 打包 typescript babel.js ide

0 人点赞