项目规范化开发探索
前因
这次在fcc2018前端大会上，听到了余澈前辈的《开源项目维护》分享，深有收获.所以站在前人的肩膀上探索探索
痛点
现在前端项目开发，主要是由代码、依赖库、文档、changelog、测试文件等等几部分组成。但是由于前端开发的不规范，大部分创业公司开发都是不考虑文档以及changelog之类的部分的，只要代码跑通，就OK。同样的，注释什么的自然也是不会去写的，整个项目就显得十分的杂乱，后来人也难以接手。
思路
其实文档、changelog之类的内容都具有一定的可预见性，遵循于一定的原则，由此可见，理论上是可以由代码来自动实现的。因此，主要的自动化处理方式便是使用jsdoc注释规则规范化注释，由此可以借助jsdoc之类的工具自动生成文档。其次，使用统一的eslint文件规范代码的风格，使用统一的prettier配置文件规范代码的样式，然后使用统一的commitlint文件规范并自动生成commit message，有了规范的commit message后，就可以使用工具提取相应的内容，自动生成changelog。由此而来，项目最繁琐的几个痛点便可以轻松简化到规范的注释以及规范的commit message两点，即可。
Husky
自动规范化项目，最核心的一个工具便是husky，简单来说，husky提供了几个钩子，可以拦截到git的比如commit、push等等操作，然后在操作前，执行某些脚本，预处理被操作的对象。
-
安装
npm install husky --save-dev -
配置
在最新版中，hasky的配置不需要写在npm script中了，直接在package.json中添加一下字段即可。
{ "husky": { "hooks": { "pre-commit": "npm run test", "pre-push": "npm run test", "...": "..." } } }
Lint-staged
Lint-staged是自动规范化项目第二重要的工具，主要功能为依次运行传入的命令数组，但是，约束命令的作用范围只会影响到git staged范围内的文件，即用git add 添加到待commit队列的文件，从而避免影响到其他文件，同时也能加快预处理脚本的速度。
-
安装
npm install --save-dev lint-staged -
配置
同样是直接在package.json文件中直接添加lint-staged的命令列表
"lint-staged": { "*.js": ["eslint --fix", "git add"] }然后，将lint-staged与husky整合:
"husky": { "hooks": { "pre-commit": "lint-staged" } }这样，便做到了每次commit的时候自动eslint将要上传的文件，然后才commit，其他没有被add的文件不会被eslint处理。
Prettier
有了以上条件后，我们便可以来添加我们的第一个预处理脚本Prettier。prettier是最出名的代码格式化工具之一。由于我们每个人的编程习惯不一样，有的人喜欢分号，有些人不喜欢分号，有些人四个空格缩进，有些人八个空格缩进。如果强制每个人编码习惯一样，总是让人比较难受，所以这里可以约定一个统一个代码风格配置文件，在提交的时候自动处理代码，将它们格式化为统一的风格，这样每个人写代码的时候可以按着自己的习惯写，最后提交的代码又是风格一致的，两全其美。
-
安装
yarn global add prettier -
配置
https://prettier.io/docs/en/configuration.html
-
整合到lint-staged
"*.js": [ "prettier --config ./.prettierrc --write", "git add" ]
Commit-message 规范
要从commit message中提取到有用的数据用来生成CHANGELOG，那么commit message就必须有一个相对固定的格式，同时这个格式能够基本覆盖到所有的comm操作类型。
目前比较流行的格式为Angular Git Commit Guidelines
大致的格式如下:
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
- <type>:本次commit的类型，比如新特性feat，bug修复fix等等
- <scope>:本次操作波及的范围，可自定义
- <BLANK LINE>:空行
- <body>:可选，描述本次commit的动机等等，如需换行，在行尾添加"|"
- <footer>:可选，描述如解决了某个issue，或者这次为breaking change，对应的upgrade的方法等等
Commitizen
由上可见，一个规范的commit message其实十分的麻烦，对于一个连注释都不写的公司来说，要求同事都这样规范的写commit message显然是不可能的。所以，我们需要工具，能够自动生成这样格式的commit message，所以有了工具commitizen。
-
安装
npm install -g commitizen
安装完成后，系统便会多出git cz命令，git cz能够完全的代替git commit命令，拥有其所有的参数，使用方法完全一样，同时也可以被husky所拦截到.
commitizen采用了询问的方式来获取对应的commit信息，大致页面如下:
cz-conventional-changelog
有了格式化的commit message后，我们便可以用来自动生成changelog了，好在Commitizen有着配套的工具。
commitizen init cz-conventional-changelog --save-dev --save-exact
使用commitizen初始化cz-conventional-changelog，他会作为一个adapter来解析对应的内容。由于commit message的规范其实有很多种，angular的规范只是很常用的规范之一，所以对于不同的规范需要不同的adapter才能解析出对应的数据，不过因为和commitizen整合，所以不需要考虑格式和adapter不匹配的问题，毕竟格式是有commitizen自动生成的。
Commitlint
虽然有了自动生成工具，但是肯定还是有偷懒的小伙伴懒得去写，直接随便写个message就上传，这样的话就会破坏掉原有的格式（强迫症也会表示很难受啊喂），所以我们需要一个lint工具来替我们检测对应的commit message是不是一个合法的commit message。当然，这个工具也应该自动调用，在上传的时候自动检测。
-
安装
npm install --save-dev @commitlint/config-conventional @commitlint/cli安装conventional格式的lint以及对应的cli（commitlint也有其他格式的adapter，若使用的是其他规范，请参考官网）
-
配置
echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js你要是不嫌麻烦，新建对应的文件，然后把内容拷进去效果也一样。
-
与husky整合
{ "husky": { "hooks": { "commit-msg": "commitlint -E HUSKY_GIT_PARAMS" } } }这样便可以做到在commit的时候自动检测commit message是否合法了
standard-version
有了对应的adapter，就可以提取commit-message的信息，从而生成changelog。我们可以使用Conventional Changelog来生成changelog，不过Conventional Changelog是生成changelog的基本库，它们更推荐使用基于它们来实现的库standard-version来进行CHANGELOG的生成：
-
安装
npm i --save-dev standard-version -
在package中使用npm script整合standard-version
{ "scripts": { "release": "standard-version" } }
这样，我们每次到了需要发布一个新版本的时候，使用npm run release就可以生成上一个版本到现在的CHANGELOG，同时standard-version本身也可以用作项目的版本管理工具。
JSDOC
jsdoc是一个通过注释自动生成文档的工具，虽然jsdoc已经很久没有人维护了，很多新语法都不支持（连PR都没人去通过了，感觉凉凉了），不过jsdoc的注释语法却是注释生成文档的通用语法，而且和vscode等编辑器整合的非常好，简单的snippet便可以生成对应的注释，如果再加上document-this插件，就基本OK了，写注释十分轻松。不过现在注释生成文档的工具，要么很丑，要么就是很久没维护了，就很蛋疼emmmm，只能说将就着用一用。。。。
待续。。。。。