我正在参加「掘金·启航计划」

前两篇webpack的文章写了多种场景需求下webpack的配置，修改开发框架时运用可以解决很多问题，然而总有场景需要从头开始，比如上级莫名其妙的开发需求以及公司独特的开发流程，这时候往往需要从头编写自己的构建配置，以适应这些规定。只是提供一些关注点，有需要可以尝试网上的一些“从零实现CRA”等工程。对于掌握前端工具链大有裨益。

构建配置

构建配置包

意义

通用性
- 业务开发者无需关心构建配置
- 统一团队构建脚本
可维护性
- 构建配置合理拆分
- README.md和ChangeLog
质量
- 冒烟测试、单元测试、测试覆盖率
- 持续集成

可选方案

多个配置文件管理不同环境的构建：webpack --config webapck.xxx.js
将构建配置成库（例如：hjs-webpack、Neutrino、webpack-blocks）
抽成一个工具进行管理（例如：CRA、kyt、nwb）
所有配置放在一个文件里，通过--env进行分支选择

结构设计

多个配置文件管理不同环境的webpack配置：

基础环境：webpack.base.js
- 资源解析
  - 解析ES6
  - 解析React
  - 解析CSS
  - 解析Less
  - 解析图片
  - 解析字体
- 样式增强
  - 前缀补齐
  - 单位转换：px转rem
- 目录清理
- 多页面打包
- 命令行信息显示优化
- 错误捕获和处理
- CSS提取为单独文件
开发环境：webpack.dev.js
- 代码热更新
  - CSS热更新
  - JS热更新
- sourcemap
生产环境：webpack.prod.js
- 代码压缩
- 文件指纹
- Tree shaking
- Scope Hoisting
- 速度优化
  - 基础包CDN
- 体积优化
  - 代码分割
SSR环境：webpack.ssr.js
- output的libaryTarget设置
- CSS解析ignore
……

抽离成npm包管理：

规范：Git Commit日志、README、ESLint规范、Semver规范
质量：冒烟测试、单元测试、测试覆盖率、CI

使用webpack-merge组合配置：

const merge=require('webpack-merge')
...
module.exports=merge(baseConfig,devConfig)

使用ESLint规范构建脚本

使用eslint-config-airbnb-base

eslint --fix可以自动处理空格

写法：

module.exports={
	"parser":"babel-eslint",
	"extends":"airbnb-base",
	"env":{
		"browser":true,
		"node":true
	}
}

冒烟测试

目的

在提交测试之前对软件进行的预测试，主要目的是暴露导致软件需要重新发布的基本功能失效等严重问题。

测试判断

判断内容：

构建是否成功，保证基本功能可用
每次构建完build目录是否有内容输出：
- 是否有JS、CSS等静态资源
- 是否有HTML文件

单元测试与测试覆盖率

单元测试

Mocha+chai（如果是react可以使用官方推荐的jest）

chai提供断言expect

Mocha提供描述测试文件的describe和描述测试用例的it

用法示例

const expect=require('chai').expect;
const add=require('../src/add');

describe('use expect:src/add.js',()=>{
  it('add(1,2)===3',()=>{
    expect(add(1,2).to.equal(3));
  });
})

测试覆盖率

istanbul："test": "istanbul cover ./node_modules/.bin/_mocha"

持续集成

优点

快速发现错误
防止分支大幅偏离主干

核心措施：代码集成到主干之前，必须通过自动化测试，只要有测试用例失败，便不能集成

Github较为流行的CI：Travis CI、Circle CI、Jenkins

Travis CI

使用方法：

使用Github登录Travis CI
验证账号及设置
编写.travis.yml文件

发布构建包

添加用户：npm adduser
升级版本：
- 升级版本号：npm version patch
- 升级小版本号：npm version minor
- 升级大版本号：npm version major
发布版本：npm publish

与git配合的细节：

需要git提交后再进行发布或者版本变更
版本升级时会自动提交至本地git缓存库，并自动打一个git tag，可进行push后提交。

Git Commit规范

好处

加快code review的过程
根据git commit的元数据形成changelog
后续维护着知道feature被修改的原因

技术方案

angular的git commit日志为基本规范
- 提交类型限制：feat,fix,docs,style,refactor,perf,test,chore,revert
- 提交信息分为：标题（首字母不大写，末尾无标点）、主体
日志提交时友好的类型选择提示：commitize
不符合格式的日志拒绝提交的保障机制：
- validate-commit-msg工具
- 需要同时在客户端、gitlab server hook
统一changelog文档信息生成：使用conventional-changelog-cli

提交格式：

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

feat:新增feature
fix: 修复bug
docs:仅仅修改了文档，比如READMECHANGELOGCONTRIBUTE等等
style:仅仅修改了空格、格式缩进、都好等等，不改变代码逻辑 refactor:代码重构，没有加新功能或者修复bug
perf:优化相关，比如提升性能、体验
test:测试用例，包括单元测试、集成测试等
chore:改变构建流程、或者增加依赖库、工具等
revert:回滚到上一个版本

Git hooks中增加precommit

npm install husky onventional-changelog-cli validate-commit-msg --save-dev

增加设置：

"scripts":{
	"commitmsg":"validate-commit-msg",
	"changelog":"conventional-changelog -p angular -i CHANGELOG.md -s -r 0"
}

语义化版本格式规范

semver规范格式：X.Y.Z

版本严格递增

发布重要版本时可先发布alpha，rc等先行版本

可有效减少循环依赖，减少一些依赖冲突

Semantic Versioning格式规范：

X：当做了不兼容的API更改时
Y：当做了向下兼容的功能性新增时
Z：当你做了向下兼容的问题修正时
主版本或重要次版本更新前可以发布一些测试版本：
- alpha：内部测试版本
- beta：alpha版本之后发布，会一直添加新功能
- rc（release candidate）：发行候选版本，不会新增功能，着重于除错

手记

到某个路径下：process.chdir(path.join(__dirname,"xxxx"))

webpack：可维护的构建配置