構建配置抽離成 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組合配置
> merge = require("webpack-merge")
...
> merge(
... { a: [1], b: 5, c: 20 },
... { a: [2], b: 10, d: 421 }
... )
{ a: [ 1, 2 ], b: 10, c: 20, d: 421 }
合並配置:module.exports = merge(baseConfig, devConfig);
功能模塊設計
目錄結構設計
lib 放置源代碼
test 放置測試代碼
|- /test
|- /lib
|- webpack.dev.js
|- webpack.prod.js
|- webpack.ssr.js
|- webpack.base.js
|- README.md
|- CHANGELOG.md
|- .eslinrc.js
|- package.json
|- index.js
使用 ESLint 規范構建腳本
使用 eslint-config-airbnb-base
eslint --fix 可以自動處理空格
module.exports = {
"parser": "babel-eslint", "extends": "airbnb-base", "env": {
"browser": true,
"node": true }
};
冒煙測試 (smoke testing)
冒煙測試是指對提交測試的軟件在進行詳細深入的測試之前而進行的預測試，這種 預測試的主要目的是暴露導致軟件需重新發布的基本功能失效等嚴重問題。
冒煙測試執行
-
構建是否成功
-
每次構建完成 build 目錄是否有內容輸出
·是否有 JS、CSS 等靜態資源文件 ·是否有 HTML 文件
判斷構建是否成功
在示例項目里面運行構建，看看是否有報錯
判斷基本功能是否正常
- 編寫 mocha 測試用例
- 是否有 HTML 文件
單元測試與測試覆蓋率
編寫單元測試用例
- 技術選型:Mocha + Chai
- 測試代碼:describe, it, except
- 測試命令:mocha add.test.js
// add.test.js
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));
});
});
單元測試接入
\1. 安裝 mocha + chai npm i mocha chai -D
\2. 新建 test 目錄，並增加 xxx.test.js 測試文件
\3. 在 package.json 中的 scripts 字段增加 test 命令
"scripts": {
"test": "node_modules/mocha/bin/_mocha”
}
\4. 執行測試命令
npm run test
持續集成的作用
優點:
-
快速發現錯誤
-
防止分支大幅偏離主干
核心措施是，代碼集成到主干之前，必須通 過自動化測試。只要有一個測試用例失敗， 就不能集成。
Github 最流行的 CI
接入 Travis CI
- https://travis-ci.org/ 使用 GitHub 賬號登錄
- 在 https://travis-ci.org/account/repositories 為項目開啟
- 項目根目錄下新增 .travis.yml
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 被修改的原因
技術方案
提交格式要求:
本地開發階段增加 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"
}
Changelog 生成
開源項目版本信息案例
- 軟件的版本通常由三位組成，形如: 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 版不會再加入新的功能了，主 要着重於除錯。