摘要：公司不同，规范的内容形式检查方式也不同，但最终是要验收你的规范。你的代码不合规范，提交都提交不上去，这样就能从入口上保证代码的规范性。
背景
越来越多的前端项目开始使用typescript这门静态检查语言了，它包括很多很棒的功能点，在这里就不细述，根据静态语法检查和.d.ts生成的代码提示两大特性，我们就可以来制定并且检查代码规范，现在我们来详细说一下。
代码规范代码规范大家应该是从开始写第一行代码开始别人就开始和你说，要遵循xx代码规范。公司不同，规范的内容、形式、检查方式也不同，但最终是要验收你的规范。
如果是通过leader code review方式来检查代码，那效率也就太低了，最好的方式就是在GIT提交之前做检查。你的代码不合规范，提交都提交不上去，这样就能从入口上保证代码的规范性。
我们再说看下前端的代码规范情况，前端的代码主要就是js的代码，因为js的灵活性以及随意性，让工具来检查代码的规范成为不可能，这也是我一直头疼的事，因为规范这种东西，说再多遍，不来点强制手段，组内之前也是不可能达成一致的。直到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中用到的代码检查工具，用力点我
检查失败的情况
检查成功的情况
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/107269.html
摘要：对于项目的编码规范而言，主要有两种选择和。此外由于性能问题，官方决定全面采用，甚至把仓库作为测试平台，而的解析器也成为独立项目，专注解决双方兼容性问题。最近在我的项目的编码规范中全量的用代替了针对其中遇到的问题做一个记录。 对于Typescript项目的编码规范而言，主要有两种选择ESLint和TSLint。ESLint不仅能规范js代码，通过配置解析器，也能规范TS代码。此外由...
摘要：对于项目的编码规范而言，主要有两种选择和。此外由于性能问题，官方决定全面采用，甚至把仓库作为测试平台，而的解析器也成为独立项目，专注解决双方兼容性问题。最近在我的项目的编码规范中全量的用代替了针对其中遇到的问题做一个记录。 对于Typescript项目的编码规范而言，主要有两种选择ESLint和TSLint。ESLint不仅能规范js代码，通过配置解析器，也能规范TS代码。此外由...
摘要：对于项目的编码规范而言，主要有两种选择和。此外由于性能问题，官方决定全面采用，甚至把仓库作为测试平台，而的解析器也成为独立项目，专注解决双方兼容性问题。最近在我的项目的编码规范中全量的用代替了针对其中遇到的问题做一个记录。 对于Typescript项目的编码规范而言，主要有两种选择ESLint和TSLint。ESLint不仅能规范js代码，通过配置解析器，也能规范TS代码。此外由...
阅读 1859·2021-11-19 09:40
阅读 2109·2021-10-09 09:43
阅读 3164·2021-09-06 15:00
阅读 2794·2019-08-29 13:04
阅读 2739·2019-08-26 11:53
阅读 3465·2019-08-26 11:46
阅读 2304·2019-08-26 11:38
阅读 371·2019-08-26 11:27
