webpack全方位由浅到深讲解，做到简历上真正所谓的“熟悉”(系列二)

xiao_guo
1,353 阅读4分钟

b840c72e59dd5b880ed68bb8d10b6c62.jpeg

注意：文章基于“webpack4”讲解

编写可维护的webpack构建配置

构建配置抽离成 npm 包的意义

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

构建配置包设计

  • 通过多个配置文件管理不同环境的webpack配置
    • 基础配置： webpack.base.js
    • 开发环境： webpack.dev.js
    • 生成环境： webpack.prod.js
    • SSR环境： webpack.ssr.js ...
  • 抽离成一个 npm 包统一管理
    • 规范 ： Git commit 日志、README、ESLint规范、Semver规范
    • 质量 : 冒烟测试、单元测试、测试覆盖率和 CI

通过webpack-merge组合配置

  • 合并配置： module.exports = merge(baseConfig, devConfig);

功能模块设计和目录结构

image.png

使用ESLint规范构建脚本

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

冒烟测试执行

  • 构建是否成功
  • 每次构建完成 build 目录是否有内容输出
    • 是否有 JS、CSS 等静态资源文件
    • 是否有 HTML 文件

判断构建是否成功

  • 在示例项目里面运行构建，看看是否有报错

判断基本功能是否正常

  • 编写 mocha 测试用例
    • 是否有 JS、CSS 等静态资源文件
    • 是否有 HTML 文件

单元测试与测试覆盖率

  • 技术选型：Mocha + Chai
  • 测试代码：describe, it, except
  • 测试命令：mocha add.test.js

单元测试接入

    1. 安装 mocha + chai npm i mocha chai -D
    1. 新建 test 目录，并增加 xxx.test.js 测试文件
    1. 在 package.json 中的 scripts 字段增加 test 命令 "scripts": { "test": "node_modules/mocha/bin/_mocha” },
    1. 执行测试命令 npm run test

持续集成的作用

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

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

接入 Travis CI

travis.yml 文件内容

  • install 安装项目依赖
  • script 运行测试用例

发布到 npm

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

Git 规范和 Changelog 生成

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

提交格式要求

image.png

本地开发阶段增加 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" 
}

开源项目版本信息案例

  • 软件的版本通常由三位组成，形如： X.Y.Z
  • 版本是严格递增的，此处是：16.2.0 - > 16.3.0 -> 16.3.1
  • 在发布重要版本时，可以发布alpha, rc 等先行版本
  • alpha和rc等修饰版本的关键字后面可 以带上次数和meta信息

遵守 semver 规范的优势

  • 优势：
    • 避免出现循环依赖
    • 依赖冲突减少

语义化版本（Semantic Versioning）规范格式

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

先行版本号

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

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

代码仓库： github.com/glihui/guo-…

最后：

如果你有梦想，一定要来大城市，这里可以帮您实现你想要的

有些梦想，需要借助城市的力量才能实现

其它系列文章链接

avatar
文章
阅读
粉丝