前因

    这次在fcc2018前端大会上,听到了余澈前辈的《开源项目维护》分享,深有收获.所以站在前人的肩膀上探索探索

痛点

    现在前端项目开发,主要是由代码、依赖库、文档、changelog、测试文件等等几部分组成。但是由于前端开发的不规范,大部分创业公司开发都是不考虑文档以及changelog之类的部分的,只要代码跑通,就OK。同样的,注释什么的自然也是不会去写的,整个项目就显得十分的杂乱,后来人也难以接手。

思路

    其实文档、changelog之类的内容都具有一定的可预见性,遵循于一定的原则,由此可见,理论上是可以由代码来自动实现的。因此,主要的自动化处理方式便是使用jsdoc注释规则规范化注释,由此可以借助jsdoc之类的工具自动生成文档。其次,使用统一的eslint文件规范代码的风格,使用统一的prettier配置文件规范代码的样式,然后使用统一的commitlint文件规范并自动生成commit message,有了规范的commit message后,就可以使用工具提取相应的内容,自动生成changelog。由此而来,项目最繁琐的几个痛点便可以轻松简化到规范的注释以及规范的commit message两点,即可。

Husky

    自动规范化项目,最核心的一个工具便是husky,简单来说,husky提供了几个钩子,可以拦截到git的比如commit、push等等操作,然后在操作前,执行某些脚本,预处理被操作的对象。

Lint-staged

    Lint-staged是自动规范化项目第二重要的工具,主要功能为依次运行传入的命令数组,但是,约束命令的作用范围只会影响到git staged范围内的文件,即用git add 添加到待commit队列的文件,从而避免影响到其他文件,同时也能加快预处理脚本的速度。

Prettier

    有了以上条件后,我们便可以来添加我们的第一个预处理脚本Prettier。prettier是最出名的代码格式化工具之一。由于我们每个人的编程习惯不一样,有的人喜欢分号,有些人不喜欢分号,有些人四个空格缩进,有些人八个空格缩进。如果强制每个人编码习惯一样,总是让人比较难受,所以这里可以约定一个统一个代码风格配置文件,在提交的时候自动处理代码,将它们格式化为统一的风格,这样每个人写代码的时候可以按着自己的习惯写,最后提交的代码又是风格一致的,两全其美。

Commit-message 规范

   要从commit message中提取到有用的数据用来生成CHANGELOG,那么commit message就必须有一个相对固定的格式,同时这个格式能够基本覆盖到所有的comm操作类型。

目前比较流行的格式为Angular Git Commit Guidelines

大致的格式如下:

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

Commitizen

    由上可见,一个规范的commit message其实十分的麻烦,对于一个连注释都不写的公司来说,要求同事都这样规范的写commit message显然是不可能的。所以,我们需要工具,能够自动生成这样格式的commit message,所以有了工具commitizen。

cz-conventional-changelog