webpack 構建配置抽離成 npm 包
構建配置抽離成 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 版不會再加入新的功能了，主 要著重於除錯。