构建配置包设计

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

通用性

  • 业务开发者无需关注构建配置
  • 统一团队构建脚本

可维护性

  • 构建配置合理的拆分
  • README 文档、ChangeLog 文档等

质量

  • 冒烟测试、单元测试、测试覆盖率

  • 持续集成

    构建配置管理的可选方案

    通过多个配置文件管理不同环境的构建，webpack —config 参数进行控制
    将构建配置设计成一个库，比如：hjs-webpack、Neutrino、webpack-blocks
    抽成一个工具进行管理，比如：create-react-app, kyt, nwb
    将所有的配置放在一个文件，通过 —env 参数控制分支选择

    构建配置包设计

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

  • 基础配置：webpack.base.js

  • 开发环境：webpack.dev.js
  • 生产环境：webpack.prod.js
  • SSR环境：webpack.ssr.js
  • ……

抽离成一个 npm 包统一管理

  • 规范：Git commit日志、README、ESLint 规范、Semver 规范

  • 质量：冒烟测试、单元测试、测试覆盖率和 CI

    通过 webpack-merge 组合配置

    1. > merge = require("webpack-merge")
    2. ... > merge(
    3. ... { a: [1], b: 5, c: 20 },
    4. ... { a: [2], b: 10, d: 421 }
    5. ... )
    6. { a: [ 1, 2 ], b: 10, c: 20, d: 421 }

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

    功能模块设计和目录结构

    功能模块设计

    截屏2022-02-17 下午9.37.39.png

    目录结构设计

    lib 放置源代码
    test 放置测试代码
    截屏2022-02-17 下午9.39.41.png

    使用Eslint规范构建脚本

    使用 eslint-config-airbnb-base
    eslint —fix 可以自动处理空格

    1. module.exports = {
    2. "parser": "babel-eslint",
    3. "extends": "airbnb-base",
    4. "env": {
    5.   "browser": true,
    6.   "node": true
    7. }
    8. };

    冒烟测试介绍和实际运用

    冒烟测试 (smoke testing)

    冒烟测试是指对提交测试的软件在进行详细深入的测试之前而进行的预测试，这种预测试的主要目的是暴露导致软件需重新发布的基本功能失效等严重问题。

    冒烟测试执行

    构建是否成功
    每次构建完成 build 目录是否有内容输出

  • 是否有 JS、CSS 等静态资源文件

  • 是否有 HTML 文件

    判断构建是否成功

    在示例项目里面运行构建，看看是否有报错截屏2022-02-18 下午3.16.30.png

    判断基本功能是否正常

    编写 mocha 测试用例

  • 是否有 JS、CSS 等静态资源文件

  • 是否有 HTML 文件

截屏2022-02-18 下午3.17.09.png

单元测试和测试覆盖率

截屏2022-02-18 下午3.18.07.png

编写单元测试用例

截屏2022-02-18 下午3.18.54.png
单元测试接入
1. 安装 mocha + chai
npm i mocha chai -D
2. 新建 test 目录，并增加 xxx.test.js 测试文件
3. 在 package.json 中的 scripts 字段增加 test 命令

  1. "scripts": {
  2.     "test": "node_modules/mocha/bin/_mocha”
  3. },
  1. 执行测试命令
    npm run test

    持续集成和Travis CI

    持续集成的作用

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

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

Github 最流行的 CI

截屏2022-02-18 下午3.25.05.png

接入 Travis CI

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

    travis.yml 文件内容

    install 安装项目依赖
    script 运行测试用例
    截屏2022-02-18 下午3.36.49.png

    发布构建包到npm社区

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

发布版本：npm publish

Git Commit规范和changelog生成

良好的 Git commit 规范优势：

  • 加快 Code Review 的流程
  • 根据 Git Commit 的元数据生成 Changelog

  • 后续维护者可以知道 Feature 被修改的原因

    技术方案截屏2022-02-18 下午3.38.07.png

    提交格式要求截屏2022-02-18 下午3.38.53.png

    本地开发阶段增加 precommit 钩子

    安装 husky
    npm install husky —save-dev
    通过 commitmsg 钩子校验信息截屏2022-02-18 下午3.41.56.png

    Changelog 生成

    截屏2022-02-18 下午3.42.33.png

    语义化版本规范格式

    开源项目版本信息案例

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

    遵守 semver 规范的优势截屏2022-02-18 下午3.45.06.png

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

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

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

    先行版本号

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

  • alpha：是内部测试版，一般不向外部发布，会有很多 Bug。一般只有测试人员使用。

  • beta：也是测试版，这个阶段的版本会一直加入新的功能。在 Alpha 版之后推出
  • rc：Release Candidate) 系统平台上就是发行候选版本。RC 版不会再加入新的功能了，主要着重于除错。