前端UI組件【免費下載鏈接】formily Cross Device High Performance Normal Form/Dynamic(JSON Schema) Form/Form Builder -- Support React/React Native/Vue 2/Vue 3項目地址https://gitcode.com/gh_mirrors/fo/formily點擊查看免費下載本篇指南圍繞 Formily 官方貢獻(xiàn)文檔展開完整梳理了向這個阿里巴巴開源的跨端表單框架提交代碼的端到端流程從 Fork 倉庫、按規(guī)范創(chuàng)建分支、遵循代碼風(fēng)格提交代碼到發(fā)起符合 Conventional Commits 規(guī)范的 Pull Request、通過多輪 Review 完成合并再到同步上游變更與本地構(gòu)建/測試/文檔開發(fā)。讀完本文你將掌握一套可直接上手操作的 Formily 貢獻(xiàn)工作流并能結(jié)合倉庫源碼理解其 monorepo 工程約束yarn workspaces lerna jest commitlint使你的第一次 PR 順暢通過審核。為什么成為 Formily 的貢獻(xiàn)者Formily 是阿里巴巴唯一官方向外公布的開源表單框架功能和質(zhì)量都有一定保證社區(qū)使用者眾多。參與貢獻(xiàn)不僅能讓 Formily 變得更強大也能讓更多開發(fā)者享受到更好的表單開發(fā)體驗。項目維護(hù)團(tuán)隊非常感謝任何向本項目發(fā)起 Pull Request 的同學(xué)。無論你擅長內(nèi)核邏輯、UI 組件還是文檔寫作都能在 Formily 社區(qū)找到適合自己的貢獻(xiàn)方向。關(guān)于項目背景與快速上手可先閱讀 docs/guide/index.md 與 docs/guide/quick-start.md。貢獻(xiàn)范圍你能做些什么Formily 的貢獻(xiàn)類型非常寬泛官方文檔將貢獻(xiàn)內(nèi)容劃分為五類貢獻(xiàn)類型具體內(nèi)容features新增 / 修改功能特性unitest新增 / 修改單元測試bugfix修復(fù)現(xiàn)有 issue 中的問題doc文檔改進(jìn)other其他如示例、構(gòu)建腳本、性能優(yōu)化等其中「單測」在 Formily 中被視為與功能特性同等重要的貢獻(xiàn)方向——這與倉庫的工程質(zhì)量體系直接相關(guān)根目錄 jest.config.js 中collectCoverage: true表明倉庫默認(rèn)開啟覆蓋率統(tǒng)計新增功能若沒有對應(yīng)的單測覆蓋將很難通過審核詳見下文「PR 規(guī)范」。端到端貢獻(xiàn)流程第一步Fork 并克隆倉庫Formily 采用典型的 GitHub Fork 協(xié)作模型訪問原始倉庫alibaba/formily點擊 Fork 按鈕將倉庫復(fù)制到你自己的 GitHub 賬號下即目標(biāo)倉庫。將 fork 后的倉庫克隆到本地并進(jìn)入項目目錄$ git clone 你的 fork 倉庫地址 $ cd formily第二步按規(guī)范創(chuàng)建分支原始倉庫的默認(rèn)分支是master對應(yīng) alibaba/formily master你 fork 后本地開發(fā)不應(yīng)直接改master而應(yīng)基于它創(chuàng)建功能分支。官方建議的分支命名規(guī)則為[feat]-[name][feat]是分支類型可選值為feat功能、unitest單測、docs文檔、bugfix缺陷修復(fù)、other其他[name]是分支名字自定義即可。示例分支名unittest-core的含義是「對核心包補充單測」$ git checkout -b unittest-core master分支命名與 PR 的 type 前綴保持一致的命名習(xí)慣能讓維護(hù)者在 Pull Request 列表里一眼識別改動意圖。第三步提交代碼與代碼風(fēng)格開發(fā)完成后先在你 fork 出的倉庫本地提交再推送并發(fā)起 Pull Request。Formily 對代碼風(fēng)格有兩條硬性要求2 空格縮進(jìn)不使用分號除非有明確說明代碼中不得附帶任何 console 相關(guān)方法及 debugger。這兩條規(guī)范并非空談倉庫工程層已通過工具強制落地根目錄 package.json 的lint-staged配置會在 pre-commit 階段對*.{ts,tsx,js}依次執(zhí)行eslint與pretty-quickprettier 的暫存文件格式化器對*.md執(zhí)行pretty-quick。而devDependencies中同時引入了eslint-config-prettier說明 ESLint 規(guī)則與 prettier 格式化風(fēng)格無分號、雙空格是收斂一致的。也就是說只要本地跑通yarn lint提交的代碼風(fēng)格基本就能滿足倉庫要求。$ git add 改動文件 $ git commit -m feat(core): add unit test $ git push origin unittest-core第四步發(fā)起 Pull Request推送分支后在你 fork 的倉庫頁面向原始倉庫發(fā)起 Pull Request。需要特別注意 PR 界面的目標(biāo)指向左側(cè)base repository必須是原始倉庫alibaba/formily的master分支右側(cè)head repository是你 fork 倉庫的當(dāng)前功能分支。官方提示左側(cè)是目標(biāo)倉庫base repository 為 alibaba/formily master右側(cè)是當(dāng)前分支所在你 fork 的倉庫兩者切勿選反。第五步審核與合并Formily 的審核采用多輪 Review 流程janryWang負(fù)責(zé)最終裁決該改動是否合并其他維護(hù)者與社區(qū)成員也會在 PR 中參與討論討論記錄完整保存在 PR 頁面中釘釘群會同步收到相應(yīng)通知。當(dāng) Pull Requests 列表中的該 PR 狀態(tài)變?yōu)镃losed時即表示合并成功。PR 與 Commit Message 規(guī)范Formily 要求 PR 名稱遵循type(scope): subject格式例如feat(core): add unit test除了名稱格式還有三條硬性要求維度要求PR 內(nèi)容在描述中列舉本次改動的內(nèi)容PR 要求新增功能注釋盡量清晰對應(yīng)的單測覆蓋要盡可能覆蓋BUGFIX 要求若修復(fù)內(nèi)容與 issues 相關(guān)請在 PR 內(nèi)容中附上相關(guān)的 issueID其中「注釋清晰 單測覆蓋」與倉庫質(zhì)量體系一一對應(yīng)Formily 的核心包 packages/core/src/tests下已沉淀了field.spec.ts、form.spec.ts、effects.spec.ts、lifecycle.spec.ts、array.spec.ts等 11 個測試文件新增功能參照這些既有用例編寫測試是最穩(wěn)妥的方式。Commit Message 同樣被工程化約束根目錄 commitlint.config.js 通過extends: [commitlint/config-conventional]強制提交信息遵循 Conventional Commits 規(guī)范且根 package.json 的 ghooks 配置中commit-msg鉤子會執(zhí)行commitlint --edit——也就是說Commit 信息不符合type(scope): subject格式將無法提交成功這一約束從源頭保證了 PR 名稱與提交歷史的規(guī)范性。保持 Fork 與上游同步PR 合并或社區(qū)有新提交后你需要定期把原始倉庫的最新變更同步到 fork 倉庫避免功能分支與上游 master 產(chǎn)生過多沖突。官方給出的同步流程如下# 1. 為本地倉庫添加 upstream即原始倉庫 $ git remote add upstream 原始倉庫地址 # 2. 獲取原始倉庫的最新變更 $ git fetch upstream # 3. 將原始倉庫的改動同步到本地目標(biāo)分支不指定分支名時默認(rèn)同步到當(dāng)前分支 $ git pull upstream master同步完成后再推送回你自己的 fork 倉庫git push origin 分支名即可基于最新代碼繼續(xù)開發(fā)或更新 PR。本地開發(fā)構(gòu)建、測試與 LintFormily 是一個典型的多包 monorepo根目錄 package.json 的workspaces字段聲明了packages/*與devtools/*兩個工作區(qū)lerna.json 中useWorkspaces: true、npmClient: yarn因此推薦使用yarn 1.x進(jìn)行包管理與跨包腳本編排。安裝依賴$ cd formily $ yarn install # 安裝整體項目依賴構(gòu)建所有項目$ yarn build # 構(gòu)建所有項目build腳本的真實定義為rimraf -rf packages/*/{lib,dist,esm} lerna run build先清理所有子包的歷史產(chǎn)物lib / dist / esm再通過 lerna 并行觸發(fā)各子包的構(gòu)建。以 packages/core/package.json 為例單個子包的構(gòu)建包含build:cjstsc 編譯 CommonJS 到 lib、build:esmtsc 編譯 ES Module 到 esm與build:umdrollup 打包 UMD 到 dist三個階段。執(zhí)行單元測試$ yarn test # 執(zhí)行單元測試test腳本實際運行jest --coverage。結(jié)合 jest.config.js 可以看到倉庫的測試約定preset: ts-jest直接對 TypeScript 源碼運行測試testMatch: [**/__tests__/**/*.spec.[jt]s?(x)]測試文件統(tǒng)一放在各包的__tests__目錄、以.spec.ts(x)命名如packages/core/src/__tests__/field.spec.tstestEnvironment: jsdom可在 Node 環(huán)境模擬 DOMsetupFilesAfterEnv引入 global.config.ts為所有用例注入sleep、requestAnimationFrame等全局輔助函數(shù)collectCoverage: true默認(rèn)開啟覆蓋率統(tǒng)計。當(dāng)只需驗證某個子包時倉庫還提供了細(xì)粒度的測試腳本例如yarn test:core、yarn test:react、yarn test:vue、yarn test:antd、yarn test:next、yarn test:reactive、yarn test:schema、yarn test:shared、yarn test:path等對應(yīng)jest packages/pkg/的定向執(zhí)行調(diào)試時可使用yarn test:core:watch進(jìn)入 watch 模式。Lint 與代碼格式化$ yarn lint # 執(zhí)行 eslint .ESLint 覆蓋.ts/.tsx/.js與 Markdown 文檔配合 prettier 實現(xiàn)風(fēng)格統(tǒng)一。提交前建議本地依次跑yarn lint、yarn test與yarn build確保 CI 與 pre-commit 鉤子lint-staged不會攔截你的提交。文檔站開發(fā)Formily 的文檔站基于 dumi 構(gòu)建根 package.json 的start腳本為dumi devbuild:docs為dumi build因此文檔類貢獻(xiàn)可以直接在本地實時預(yù)覽# 主項目文檔docs/ 目錄 $ yarn start # 內(nèi)核項目文檔packages/core/docs $ yarn workspace formily/core start # React 項目文檔packages/react/docs $ yarn workspace formily/react start # Vue 項目文檔packages/vue/docs $ yarn workspace formily/vue start # Antd 項目文檔packages/antd/docs $ yarn workspace formily/antd start # FusionNext項目文檔packages/next/docs $ yarn workspace formily/next start # Reactive 項目文檔packages/reactive/docs $ yarn workspace formily/reactive start每個子包都在自身docs/目錄下維護(hù)獨立文檔例如 packages/core/docs/guide 中的架構(gòu)、字段、表單與 MVVM 講解以及 packages/react/docs、packages/vue/docs 的 API 文檔。本文所依據(jù)的貢獻(xiàn)指南也有對應(yīng)的中文版本 docs/guide/contribution.zh-CN.md文檔類貢獻(xiàn)者可以對照中英版本進(jìn)行改進(jìn)。Monorepo 結(jié)構(gòu)速覽源碼佐證理解倉庫結(jié)構(gòu)能幫助你快速定位改動所在包。從各子包 package.json 的name字段可以看到 Formily 當(dāng)前的主要工作區(qū)成員子包定位formily/core表單內(nèi)核字段、生命周期、狀態(tài)機formily/react / formily/vueReact / Vue 適配層formily/antd / formily/next / formily/elementAnt Design / Fusion Next / Element 組件庫formily/reactive / formily/reactive-react / formily/reactive-vue響應(yīng)式模型與框架橋接formily/json-schema / formily/validator / formily/path / formily/shared / formily/gridJSON Schema 編譯、校驗、路徑解析、共享工具等基礎(chǔ)能力跨包開發(fā)時根目錄 tsconfig.json 的paths將formily/*映射到各包的src目錄保證 monorepo 內(nèi)部以源碼形態(tài)互相引用、調(diào)試所見即所得。總結(jié)向 Formily 貢獻(xiàn)代碼的完整鏈路可以概括為Fork 倉庫 → 按類型-名稱規(guī)則建分支 → 遵循「2 空格、無分號、無 console/debugger」風(fēng)格開發(fā) → 以type(scope): subject格式提交并發(fā)起 PR → 補充清晰注釋與單測覆蓋 → 通過多輪 Review 后合并 → 定期用 upstream 同步上游變更。整個流程中commitlint、lint-staged、jest 覆蓋率與 lerna 多包構(gòu)建共同構(gòu)成了質(zhì)量閘門理解這些工程約束不僅能讓你的 PR 一次通過也能讓你更深入地理解 Formily 的協(xié)作方式與代碼組織哲學(xué)。贊分享前端UI組件【免費下載鏈接】formily Cross Device High Performance Normal Form/Dynamic(JSON Schema) Form/Form Builder -- Support React/React Native/Vue 2/Vue 3項目地址https://gitcode.com/gh_mirrors/fo/formily點擊查看免費下載相關(guān)推薦MMPose 開源貢獻(xiàn)指南從 Fork 到合入的完整 PR 流程與代碼規(guī)范實戰(zhàn)MMPose 開源貢獻(xiàn)指南從 Fork 到合入的完整 PR 流程與代碼規(guī)范實戰(zhàn) 導(dǎo)讀 本文基于 MMPose 官方中文貢獻(xiàn)指南結(jié)合倉庫內(nèi)真實的 CI 工作流計算機視覺人工智能深度學(xué)習(xí)Flower 貢獻(xiàn)工作流實戰(zhàn)從 Fork 倉庫到合并第一個 PR 的完整指南Flower 貢獻(xiàn)工作流實戰(zhàn)從 Fork 倉庫到合并第一個 PR 的完整指南 本文基于 Flower 官方文檔《Contribute on GitHub》整理人工智能聯(lián)邦學(xué)習(xí)機器學(xué)習(xí)深度學(xué)習(xí)爐石傳說 HsMod 插件指南3 步裝完變速、開包、換皮膚全都有爐石傳說 HsMod 插件指南3 步裝完變速、開包、換皮膚全都有 開包開到手酸、過場動畫磨人、界面千篇一律爐石傳說插件 HsMod 一次接住這三件事它是AI AgentAgent 工作流開發(fā)工具創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考