webpack 之 webpack 构建配置的持续集成、发布 npm、Commit 规范、语义化版本规范和 webpack 构建速度和体积优化分析

一、webpack 构建配置的持续集成、发布 npm、Commit 规范、语义化版本规范

1. 持续集成的作用，优点是快速发现错误和防止分支大幅偏离主干。核心措施是代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。
2. 接入 Travis CI，如下所示：

• https://travis-ci.org/ 使用 GitHub 账号登录
• 在 https://travis-ci.org/account/repositories 为项目开启
• 项目根目录下新增 .travis.yml

3. travis.yml 文件内容，install 安装项目依赖，script 运行测试用例，代码如下：

language: node_js

sudo: false

cache: 
  apt: true
  directories:
    - node_modules

node_js: stable #设置相应的版本

install: 
  - npm install -D #安装构建器依赖
  - cd ./test/template-project
  - npm install -D #安装模版项目依赖
 
script： 
 - npm test

4. 发布到 npm，添加用户是 npm adduser，发布版本是 npm publish，升级版本，如下所示：

• 升级补丁版本号：npm version patch
• 升级小版本号：npm version minor

5. Git 规范和 Changelog 生成，良好的 Git commit 规范优势，如下所示：

• 加快 Code Review 的流程
• 根据 Git Commit 的元数据生成 Changelog
• 后续维护者可以知道 Feature 被修改的原因

5. Git 提交格式的 技术方案如下：

• 统一团队 Git Commit 日志标准，便于后续代码 review 和版本发布
• 使用 angular 的 Git commit 日志作为基本规范，提交类型限制为 feat、fix、docs、style、refactor、perf、test、chore、revert 等，提交信息分为两部分，标题首字母不大写，末尾不要标点，主体内容正常的描述信息即可
• 日志提交时友好的类型选择提示，使用 commitize 工具
• 不符合要求格式的日志拒绝提交的保障机制，使用 validate-commit-msg 工具，需要同时在客户端，gitlab server hook 做
• 统一 changelog 文档信息生成，使用 conventional-changelog-cli 工具

6. 提交格式要求，如下所示：

• type 代表某次提交的类型，比如是修复一个 bug 还是增加一个新的 feature
• feat：新增 feature
• fix：修复 bug
• docs：仅仅修改了文档，比如 README、CHANGELOG、CONTRIBUTE 等等
• style：仅仅修改了空格、格式缩进、逗号等等，不改变代码逻辑
• refactor：代码重构，没有加新功能或者修复 bug
• perf：优化相关，比如提升性能、体验
• test：测试用例，包括单元测试、集成测试等
• chore：改变构建流程、或者增加依赖库、工具等
• revert：回滚到上一个版本

7. 本地开发阶段增加 precommit 钩子，安装 husky，通过 npm install husky --save-dev，通过 commitmsg 钩子校验信息，代码如下：

"scripts": {
  "commitmsg": "validate-commit-msg",
  "changelog": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0"
},
"devDependencies": {
   "validate-commit-msg": "^2.11.1",
   "conventional-changelog-cli ": "^1.2.0",
   "husky": "^0.13.1"
}

8. 开源项目版本，软件的版本通常由三位组成，形如 X.Y.Z。版本是严格递增的，此处是 16.2.0 > 16.3.0 > 16.3.1。在发布重要版本时，可以发布 alpha、rc 等先行版本。alpha 和 rc 等修饰版本的关键字后面可以带上次数和 meta 信息。
9. 遵守 semver 规范的优势，避免出现依赖循环，依赖冲突减少。语义化版本规范格式，如下所示：

• 主版本号，当你做了不兼容的 API 修改
• 次版本号：当你做了向下兼容的功能性新增
• 修订号：当你做了向下兼容的问题修正

10. 先行版本号，可以作为发布正式版之前的版本，格式是在修订版本号后面加上一个连接号(-)，再加上一连串以点(.) 分割的标识符，标识符可以由英文、数字和连接号([0-9A-Za-z-])组成，如下所示：

• alpha，是内部测试版，一般不向外部发布，会有很多 Bug，一般只有测试人员使用
• beta 也是测试版，这个阶段的版本会一直加入新的功能，在 Alpha 版之后推出
• rc：Release Candidate 系统平台上就是发行候选版本，RC 版不会再加入新的功能了，主要着重于除错

二、webpack 构建速度和体积优化

1. webpack 构建速度的初级分析，使用 webpack 内置的 stats，stats 是构建的统计信息，package.json 中使用 stats，代码如下：

"scripts": {
   "build:stats": "webpack --env production --json > stats.json",
}

2. 在 Node.js 中使用，代码如下：

const webpack = require('webpack');
const config = require('./webpack.config.js')('production');

webpack(config, (err, stats) => {
   if (err) {
     return console.log(err);
   }
   if (stats.hasErrors()) {
     return console.error(stats.toString('error-only'));
   }
   console.log(stats);
});

3. 速度分析可以使用 speed-measure-webpack-plugin，可以看到每个 loader 和插件执行耗时，代码如下：

const SpeedMeasurePlugin = require('speed-measure-webpack-plugin');
const smp = new SpeedMeasurePlugin();
const webpackConfig = smp.wrap({
  plugins: [
    new MyPlugin();
    new MyOtherPlugin()
  ]
});

4. 速度分析插件的作用，如下所示：

• 分析整个打包总耗时
• 每个插件和 loader 的耗时情况

5. 体积分析可以使用 webpack-bundle-analyzer，构建完成后会在 8888 端口展示大小，代码如下：

const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;

module.exports = {
  plugins: [
    new BundleAnalyzerPlugin()
  ]
};

6. 体积分析可以解决哪些问题，如下所示：

• 依赖的第三方模块文件大小
• 业务里面的组件代码大小