前端项目工程化实践

17年9月起和朋友合作了一个项目，一套组件库Antue，好听点说叫造轮子。主要是把蚂蚁金服的Ant Design给“翻译”成Vue可用的组件库。这是一个蛮正式的项目，规模也挺大，所以给了我一个实践工程化的好场景。

什么是前端工程化

阮一峰 - 前端工程简介

我认为应该是包含包管理、代码构建、代码lint、单元测试、持续集成等等的一个合集。

包管理、代码构建、lint、单测在目前的前端项目中已经是标配了，用vue-cli生成的模板天然地为大家处理好了这些问题。所以我的实践主要是最后一步，持续集成。

持续集成的流程、概念、好处等等在上面的阮一峰的文章中说得很明确了。

为什么需要

很多朋友在业务项目中很少使用持续集成，我也是，主要是业务上使用持续集成需要考虑成本是否划算，可能是做的业务都不太好吧，如果是一个公司的主航道业务，需要一直一直持续迭代持续开发，持续集成会是一个非常好的助手我猜。

而开源的，让别人使用的lib级别的东西，再怎么严谨都是不为过的，更何况，一个优秀的持续集成工作流，能保证项目的质量，让迭代成本、维护成本变低，是一件双赢的好事。

有了持续集成机制，我们可以保证每次对主干的合并后，能检查以下项：

• 开发者提交的代码是否遵循了eslint的规则，保证风格一致，无低级错误
• 开发者提交的代码是否能够通过单元测试，避免改动或重构影响其他相关的地方
• 开发者提交的代码是否能够正常build，给出一个正确的压缩包

如何做

因为这是一个github开源项目，Travis是一个非常优秀、非常方便的选择。

仅需要项目owner用github账户登录一下Travis，勾选需要启用的对应的项目。然后编写Travis的配置文件：.travis.yml即可。

配置内容也比较简单，如下：

language: node_js
node_js:
  - 8.5.0
before_install:
  - npm install
script:
  - npm run lint
  - npm test
  - npm run build
before_deploy: 
  - node scripts/generate.js -a
  - node scripts/generate.js -r
  - npm run build:site
deploy:
  provider: pages
  skip_cleanup: true
  github_token: $GH_TOKEN
  local_dir: site/dist
  on:
    branch: master

可以理解成生命周期的各个钩子吧，先npm install安装依赖，再运行正式的script：先lint，再跑单测，最后试试构建。

任一环节出错就会发邮件告知项目相关人员，可以通过查看CI的log信息来检查到底是什么问题，在本地复现、修复。

这里有一个关键问题是，如何保证大家认可Travis的结果，有很多开源项目都使用了Travis，但是我也见过不少Travis报着错，还在继续merge到master分支的项目。

其实也很好解决，只是个理念的问题，相信制度、流程，而不是人的自觉，github对项目的设定中提供了保护分支的选项，通过把master设为保护分支，可以要求pull request必须通过CI才可以合入，我们的项目还更进一步，加了一条必须有合作者的code review。

效果如何？

首先，antue的master分支的component文件夹下的组件代码，绝对没有不符合standard规范的JS代码。

其次，未来的重构中，不会有因重构导致有完善单元测试的组件出bug（很惭愧，我写的组件还没写单元测试）。

最后，任何一台安装了合适版本node的能联网的电脑，都可以完美编译该项目（也许不能，毕竟目前的开发者使用的都是mac，可能会有平台兼容性问题，吹个牛逼也不犯法不是？）。很多人的Travis配置中可能只有跑了一个单元测试，但构建这一点其实蛮重要的，给人一个能编译（构建）过的项目，有问题比不能编译过的项目会好查太多太多。

同时，有了Travis的构建通过邮件，大家能很开心很自信地往下写。

所以有兴趣的同学，欢迎参与开发这个组件库，我们一点也不担心不同开发人员的不同风格是否会导致项目变得奇怪。

还可以做什么？

看上面的配置文件，最下面的deploy说明我们用Travis进行的自动部署。

这个需求主要是这样的，主owner希望对antd进行像素级复制，所以文档网站也是用类似于andt的手法，通过markdown生成的（没有antd的毕昇系统那么叼，但也显得很专业嘿嘿）。

发布的方式是手工执行命令：

node scripts/generate.js -a
node scripts/generate.js -r
npm run build:site
git checkout gh-pages
cp ./site/dist/* ./
git add .
git commit -m '第XX次 update doc'
git push

可以看出这个部署到github pages的操作是非常的固定的，且我们又知道我们的master分支是随时处于一个待发布的OK的状态的，那么我们为什么不让每次merge到master后就自动部署到pages上去呢？

一开始我想的是通过自己编写一个bash脚本，让Travis每次来执行这个脚本，其实这个方案也是可以的，只是不好调试，费了半天劲没有解决只master版本才部署这个问题，就很伤。

查了半天Travis的文档后发现它内置的部署provider里本身就有pages这种方案（Travis文档做得挺好，就是搜索功能非常不好用），就改成目前的这样。

自动部署的效果很好，每完成一个新组件，合并master后，就可以立即看到效果，想参与github开源项目的同学走过路过不要错过，提交就可以拿着这个网页找到自己写的组件去和人吹牛逼啦！

本项目在持续集成上的实践就酱紫啦，要是还有什么需要做的好点子欢迎和我分享。