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

avatar
@腾讯科技(深圳)有限公司

当我们在开发维护一些工具类项目的时候,随着功能的丰富以及维护人员的变更,会导致代码的可持续维护性下降,因此需要一些其他工具来帮我们提高代码质量,减少一些不必要的错误。本篇我们来介绍使用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 是一个类型变量,但是你并不能迅速找到这个错误在哪里。

  • 运行困难

运行 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开发一些大型/持续维护项目的时候,经常会让人体验什么是“开发一时爽,重构火葬场”。

  • 其他注意点

对于模块的导出

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帮我们尽量减少一些低级错误是很有必要的。


关注公众号:【IVWEB社区】,每周推送精品技术周刊 。