kbone 開發規範

開發流程

首先須要將代碼倉庫 clone 下來:github.com/wechat-mini… develop 分支。html

初次將代碼 clone 下來後,須要先運行 npm run prepare 來完成 lerna 的初始化,以後才能進入開發的流程:vue

  1. 完成代碼開發
  2. 補充單元測試
  3. 在包內執行 npm run test 確保單元測試沒有問題
  4. 在 kbone 根目錄執行 npm run check 確保代碼檢查和全部包單元測試正常
  5. 在包內的 CHANGELOG.md 中補充版本更新日誌,具體格式可參考 packages/miniprogram-element/CHANGELOG.md
  6. 若有必要,須要修改 docs 目錄下的文檔
  7. 提交到 git
  8. 在 kbone 根目錄執行 npm run publish 打標籤併發布到 npm

具體規範下面進行說明:webpack

目錄規範

kbone 是一套同構方案,包含多個包,各個包之間可能會有依賴關係,故採用 lerna 來進行管理。git

包外結構

|-- docs 文檔
|-- examples 案例
|     |-- demo1
|     |-- demo2
|     |-- ...
|     |-- README.md 案例說明
|
|-- packages
|-- .eslintignore
|-- .eslintrc.js
|-- .gitignore
|-- lerna.json
|-- LICENSE
|-- package.json
|-- README.md
複製代碼

eslint 相關配置全部包統一,因此放到包外。github

包內結構

|-- src 源碼
|-- test 單元測試
|-- tool 構建相關代碼
|-- .npmignore
|-- CHANGELOG.md 更新日誌
|-- package.json
|-- README.md
複製代碼

對於部分包須要構建,則構建相關的配置、腳本須要放到 tool 目錄下;若是包還有特殊需求,亦能夠在不修改現有目錄結構的前提下在根目錄補充其餘文件和目錄(如補充 eslint 配置等)。web

案例結構

|-- build
|     |-- miniprogram.config.js kbone 插件配置
|     |-- webpack.config.js Web 端構建配置
|     |-- webpack.mp.config.js 小程序端構建配置
|
|-- src 源碼
|-- index.html Web 端入口 html 文件
|-- package.json
複製代碼

若是此 demo 不須要 Web 端的展現,能夠去掉 Web 端代碼;通常狀況下儘可能聽從此結構來編寫案例,可是也容許針對特殊狀況調整結構(如 vue-cli3 插件案例)。vue-cli

其餘規範

代碼檢查

統一走 eslint 來約束,在 kbone 根目錄下執行:npm run lint 會對各個包內的 src、test、tool 目錄下的 js 文件進行檢查,確保無任何規則失敗提示。npm

單元測試

各個包內部實現單元測試和覆蓋率檢查,統一使用 jest 工具鏈;若是涉及到自定義組件則使用 miniprogram-simulate;若是有 CI 需求,則使用 codecov 來管理覆蓋率檢查。json

包內命令統一爲:小程序

# 執行單元測試
npm run test

# 調試單元測試
npm run test-debug

# 執行覆蓋率檢查
npm run coverage

# 接入 CI 覆蓋率檢查
npm run codecov
複製代碼

PS:可參考 packages/miniprogram-element 的實現。

在包內實現完單元測試後,須要在 kbone 根目錄下的 package.json 中補充相應的執行命令,確保在 kbone 根目錄下執行 npm run test 能夠執行全部包內的單元測試。

版本規範

參考:semver.org/lang/zh-CN/

commit 信息

格式爲 [變化]: 具體操做,一條完整的示例:feature: support camera inner component

變化支持以下枚舉值:

  • feature:新增特性
  • fixed:修復 bug
  • docs:文檔更新
  • update:demo、更新日誌、構建代碼等源碼以外的一些更新調整
  • refactor:重構
  • lint:調整代碼以經過代碼檢查

分支

默認開發分支爲 develop 分支,若是須要提 pr,則以此分支爲基準。當 develop 分支穩定後會合入 master 分支。

建立其餘分支的命名規範:

  • feature-xxx:新特性分支
  • fixed-xxx:bugfix 分支
  • refactor-xxx:重構分支

合入流程:

其餘分支 ---> develop 分支 ---> master 分支

CI

目前未接入,待補充。

相關文章
相關標籤/搜索