使用 Typescript 检查你的代码规范

背景

---

愈来愈多的前端项目开始使用typescript这门静态检查语言了，它包括不少很棒的功能点，在这里就不细述，根据静态语法检查和.d.ts生成的代码提示两大特性，咱们就能够来制定而且检查代码规范，如今咱们来详细说一下。

代码规范

---

代码规范你们应该是从开始写第一行代码开始别人就开始和你说，要遵循xx代码规范。公司不一样，规范的内容、形式、检查方式也不一样，但最终是要验收你的规范。
若是是经过leader code review方式来检查代码，那效率也就过低了，最好的方式就是在GIT提交以前作检查。你的代码不合规范，提交都提交不上去，这样就能从入口上保证代码的规范性。
咱们再说看下前端的代码规范状况，前端的代码主要就是js的代码，由于js的灵活性以及随意性，让工具来检查代码的规范成为不可能，这也是我一直头疼的事，由于规范这种东西，说再多遍，不来点强制手段，组内以前也是不可能达成一致的。直到Typescript的出现，解决了这个问题。

Typescript检查的原理

---

Typescript是javascript的超集，因此ts在运行以前，得先编译成js，那么这个编译的过程，ts的编译引擎就得知道，文件里包括哪些方法，方法包含哪些参数，各参数的定义是什么，类型是什么，总之，全部源信息必须都知道，才能准确无误的把ts翻译成js。这些东西也正是咱们须要的，经过这些信息，咱们就能够对比规范和源信息，来确认是不是符合咱们制定规范的代码。

初步实现

---

顺着这个思路，我查了查typescript的官方文档，果真找到了一个，叫作Compiler API，最后的那个例子，是和咱们的需求相关的，把代码拿下来，也是能够跑通的，因此呢，下一步，就是基于这个例子进行扩展，来知足咱们本身的需求。
实现的过程，也是挺痛苦的，由于没有文档，也没有说明，幸好在vscode能够点进行看声明文件，好消息是能够看到方法的定义，坏消息就是全部的方法的声明、类型，都没有注释，部分须要本身来猜，哈哈，有总比没有强，照猫画虎，总算实现了基本功能。

官方的.d.ts大体就长这样

开发之中，有一个问题比较难解决，就是在目前可观测的API中，只能constructor能够取到返回值类型，其余方法API根本不提供，最后借助stackoverflow上提问，解决了这个问题，有兴趣的同窗能够参考下：how to use typescript Compiler API to get normal function info, eg: returnType/parameters?

检查你的代码

---

如今已经能够检查你的代码了，咱们上面也说了，最好的检查时机是开发人员提交的时候，这时会检查全部的代码，只有全部的代码都符合规范，才会提交成功，这是咱们最理想的状况。
按照这个思路，咱们能够查到，Git有不少钩子，pre-commit、commit-msg、post-commit等等，咱们使用pre-commit：提交前检查，会执行.git/hooks/pre-commit下的脚本文件，可是这个文件分布在组内全部人的笔记本中，而且不能增长版本控制。带着这样的疑问，咱们找到了pre-commit这个神器，它的实现原理也是修改上面的文件，不过它从node层屏蔽了实现细节，咱们只要在package.json里面增长一个script就能够实现咱们要的功能。

配置大概是这样：

...
"pre-commit": ["commit"],
"script":{
    ...
    "commit": "ts-node verify.ts"
    ...
}
...

这样在git里面commit（无论使用命令行仍是SourceTree这样图形界面）的时候就会执行ts-node verify.ts，检查要是失败了，就会把错误信息打印到控制台上，而且提交会失败，直到全部的已定规则都验证经过，才会提交成功。

检查失败，大体就是这样的：

还有一个更大的做用

---

咱们已经经过上一步，可以检查咱们的规范了，知道代码的全部信息，好比生成.d.ts文件！对一个对外提供的工具库来说，若是没有一套完整的.d.ts文件进行代码提示的话，那就显的太不专业了。若是要生成一个完整的提示文件，就必需要求你的类、方法、参数、返回值都要有完整的注释，这些就应该在你的代码规范中。

咱们来看一下，比较好的例子：

知道了全部的信息，生成这个文件其实就是字符串的拼接，没什么技术含量，不过生成的格式还得注意一下。

兼容全部状况的.d.ts写法

---

通常咱们使用一个库文件的时候，都会有三种用法：

import Util from 'xxx/Util'
import {DateTime, Fiel} from 'xxx/Util'
import * as Util from 'xxx/Util'

在使用的时候，这三种形式所须要的.d.ts文件的格式也是不同的，因此做为对外提供服务的库文件来讲，全部的使用方式，咱们都应该兼容。通过屡次尝试，这样格式的.d.ts文件是兼容全部用法：

export class DateTime {
    static dateFormat(....)
}

declare const exDe: {
    DateTime: typeof DateTime
}

export default exDe

源码

---

Demo的源码以及使用效果，用力点我
Demo中用到的代码检查工具，用力点我

使用效果

• 检查失败的状况

• 检查成功的状况