Formily 贡献指南：从 Fork 到 PR 合并的完整开源参与流程

前端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开源项目的开发者完整梳理了从 Fork 仓库、创建分支、编码规范、提交 PR 到审核合并的每一个环节并结合当前仓库的工程化配置monorepo、commitlint、GitHub Actions、Jest给出源码级佐证。阅读本文后你将能够规范地提交 features、单元测试、bugfix 与文档改进并熟练使用yarn workspace在本地启动 Formily 各子项目的文档与测试环境。为什么要成为 Formily 的贡献者Formily 是阿里巴巴官方开源的跨端高性能表单解决方案支持 React / React Native / Vue 2 / Vue 3覆盖普通表单、JSON Schema 动态表单与表单设计器三大场景见仓库根目录 README.md 的项目描述。正因为它拥有庞大的社区使用者每一次来自社区的贡献都会让框架变得更强大也让更多开发者获得更好的表单开发体验。贡献的价值不仅是提交代码本身通过提交 bugfix 和单测你能深入理解 Formily 的核心架构如 packages/core 的模型层与 packages/reactive 的响应式引擎通过文档改进你能帮助全球范围内的开发者降低学习成本通过参与 review 讨论你能与核心维护者及其他社区成员直接交流。项目官方对所有发起Pull Request的同学表示感谢这也是社区贡献文化的基础。我可以贡献什么Formily 的贡献类型覆盖了开源项目的方方面面官方将贡献内容划分为五类类型说明features新增或修改功能特性unitest新增或修改单元测试bugfix修复现有 issue 中报告的问题doc文档改进other其他形式的贡献其中unitest与bugfix在工程上有明确的落点仓库的 Jest 配置jest.config.js将测试文件约定为**/__tests__/**/*.spec.[jt]s?(x)也就是说每个包的__tests__目录下的*.spec.ts/tsx文件都会被自动收集执行。例如 packages/core/src/tests下的form.spec.ts、field.spec.ts、array.spec.ts等就是核心模型层的单测矩阵。新增单测时遵循这一命名与目录约定即可被测试框架无缝识别。如何贡献从 Fork 到合并的完整流程第一步拉取仓库Fork参与贡献的前提是拥有一个可自由推送的远端副本原始仓库alibaba/formily本目录为其镜像仓库克隆地址https://gitcode.com/gh_mirrors/fo/formily目标仓库将原始仓库Fork到自己名下的账号后续的所有分支与提交都推送到自己的 Fork 副本中再通过 Pull Request 回馈上游。第二步拉取分支原始仓库的主分支为alibaba/formily的masterFork 后你本地的目标分支应保持在同一个基线之上形如你的账号/formily的master。分支命名规范重要建议分支名采用[feat]-[name]格式。其中[feat]是分支类型可选值有feat功能、unitest单测、docs文档、bugfix缺陷修复、other其他[name]是自定义名称。 例如unittest-core表示为核心包补充单元测试docs-zh-cn表示中文文档改进。清晰的分支命名不仅便于维护者快速判断改动性质也与后面介绍的 PR 标题规范Conventional Commits保持一致方便 CI 自动校验。第三步提交代码开发完成后将分支推送到自己的 Fork 仓库并提交 Pull Request。提交时需遵守以下代码风格约定缩进使用2 空格语句不使用分号除特别说明外代码中不得附带任何console相关方法及debugger语句。这些约定在仓库的工程化配置中均有落地。根目录 package.json 的lint-staged配置会在提交前对*.{ts,tsx,js}自动执行eslint与pretty-quick对*.md执行pretty-quick再通过ghooks的pre-commit钩子拦截不合规的提交package.json。也就是说本地提交时规范检查是自动强制执行的而非仅靠自觉。第四步遵循 PR 规范Formily 的 PR 规范基于 Conventional Commits仓库根目录 commitlint.config.js 显式声明extends: [commitlint/config-conventional]这正是提交信息与 PR 标题的语法标准。PR 名称格式为type(scope): subject例如feat(core): add unit testPR 内容需逐条列举本次改动的内容说明改动动机与影响范围PR 要求新增的 feat 内容应尽量做到注释清晰并尽可能补充对应的单元测试覆盖BUGFIX 要求如果修复的问题与 issues 相关请在 PR 内容中附上相关的issueID。在 CI 层面这些规范被自动化强制校验.github/workflows/check-pr-title.yml 在 PR 的opened / reopened / edited / synchronize事件上运行conventional-pr-title-action使用conventional-changelog-angular预设检查PR 标题是否符合规范.github/workflows/commitlint.yml 针对formily_next分支的 push / PR 事件运行commitlint-github-action检查提交信息是否合规。仓库还提供了现成的 PR 模板 .github/PULL_REQUEST_TEMPLATE.md其中明确要求PR 标题与提交信息遵循 Commit Specific 规范并使用英文从master或formily_next创建分支新增代码必须配套测试改动 API 必须同步更新文档提交前确保npm test与npm run lint通过。提交 PR 时请保留模板内容并逐项勾选。另外完整的贡献细则可参考仓库内的 .github/CONTRIBUTING.md其中除 PR 规范外还包含Issue 报告指南该仓库的 issue 列表仅用于 bug 报告与功能请求提交前先搜索是否已有相同 issue必须清晰描述复现步骤无法复现的 issue 不会被分诊如果问题已在最新稳定版修复请说明所使用版本若已解决请及时关闭 issue。第五步审核与合并提交 PR 后改动将进入多人 review 流程核心维护者janryWang负责最终判定改动是否合并其他社区成员也会参与讨论。讨论过程会完整留存在 PR 的评论记录中钉钉群也会收到相应的通知。合并成功的标志是Pull requests 列表中的状态变为 Closed而非显示冲突或待处理。第六步同步源仓库变更到 Fork 后的仓库长期维护一个 Fork 时需要定期同步上游原始仓库的最新变更避免分支与上游脱节。官方给出的标准操作如下# 1. 在自己的本地仓库中增加一个 upstream remote指向原始仓库 $ git remote add upstream https://github.com/alibaba/formily.git # 2. 获取原始仓库最新的变更 $ git fetch upstream # 3. 将原始仓库的改动同步到本地目标分支不填则默认同步到当前分支 $ git pull upstream master [当前本地目标分支]提示若你以镜像仓库https://gitcode.com/gh_mirrors/fo/formily为起点可按同样方式将 upstream 指向该地址并定期git fetch upstreamgit pull upstream master保持同步。多提交小步、保持分支与 master 同步能显著降低合并冲突的概率。项目开发本地环境搭建与验证无论贡献哪种类型提交前都应确保改动在本地通过完整的构建与测试链路。官方给出的开发命令如下$ cd formily $ yarn install # 安装整体项目依赖 $ yarn build # 构建所有项目 $ yarn test # 执行单元测试从源码看这些命令与仓库配置完全对应依赖安装仓库是标准的Yarn Workspaces Lernamonorepo。package.json 声明了packages/*与devtools/*两个工作区lerna.json 配置npmClient: yarn、useWorkspaces: true因此yarn install一次安装即可覆盖全部子包构建根目录 package.json 的build脚本先清理各包lib / dist / esm产物再通过lerna run build并行构建所有子包。以 packages/core/package.json 为例单个包的构建包含build:cjstsc 编译 CJS、build:esmtsc 编译 ESM与build:umdrollup 产出 UMD 产物测试根目录 package.json 的test脚本为jest --coverage即全量测试并统计覆盖率。仓库还针对每个子包预置了分片测试命令便于快速验证改动所在包yarn test:core→jest packages/core/核心模型层yarn test:reactive/yarn test:react/yarn test:vue响应式与框架绑定层yarn test:schema/yarn test:path/yarn test:shared/yarn test:validator基础设施层yarn test:antd/yarn test:next组件库层各命令还提供对应的:watch变体如yarn test:core:watch开发调试时可使用CI 侧同样执行这套链路.github/workflows/ci.yml 中依次运行yarn --ignore-engines安装依赖、yarn build全量构建与yarn test:prodjest --coverage --silent即静默模式的全量覆盖测试。也就是说你的 PR 能否合并取决于本地能否通过与 CI 完全一致的 build test。提交代码前还可运行根目录 package.json 的yarn linteslint .做一次全局静态检查与lint-staged的增量检查互为补充。开发文档各子项目文档的本地启动Formily 的每个子包都内置了独立的文档站点贡献 doc 类改动时可以在本地实时预览# 主项目文档根目录基于 dumi $ yarn start # 内核项目文档formily/core $ yarn workspace formily/core start # React 项目文档formily/react $ yarn workspace formily/react start # Vue 项目文档formily/vue $ yarn workspace formily/vue start # Antd 项目文档formily/antd $ yarn workspace formily/antd start # Fusion 项目文档formily/next $ yarn workspace formily/next start # Reactive 项目文档formily/reactive $ yarn workspace formily/reactive start从各子包的package.json可以看出这些命令的底层实现主项目与多数子包core、react、antd、next、reactive 等的start脚本均为dumi dev例如 packages/react/package.jsonpackages/vue/package.json 的start为vuepress dev docs即 Vue 子包使用 VuePress 托管其docs目录packages/vue/docs各包的docs目录即文档源例如 packages/core/docs 下的api/models模型 API与guide架构与 MVVM 指南packages/antd/docs/components 下的组件文档以及 docs/guide 下的中文指南含本文所在的 contribution 系列。文档贡献的常见落点新增 API 说明、组件用法示例可参考 docs/guide/quick-start.zh-CN.md、docs/guide/index.zh-CN.md 等或为 packages/antd/docs 等组件库补充中英文对照文档。小结贡献前的自检清单综合官方贡献指南与仓库工程配置提交 PR 前建议逐项核对分支从master或formily_next创建新主题分支命名遵循[feat]-[name]规范代码风格2 空格缩进、无分号、无console/debugger本地已通过yarn lint测试yarn test或对应包的test:xxx全部通过新增代码配套__tests__/**/*.spec.[jt]s?(x)单测bugfix 在 PR 中附上 issueID文档API 或行为有变更时同步更新对应子包文档PR 标题遵循type(scope): subject如feat(core): add unit test内容逐条列出改动同步提交前执行git fetch upstream git pull upstream master确保基于最新上游沟通参与 review 讨论等待状态变更为 Closed 即合并成功。Formily 的成长依赖每一位社区成员规范的贡献流程是高效协作的基石——期待你的第一个 Pull Request。赞分享前端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点击查看免费下载相关推荐OceanBase 开源贡献指南从 Fork 到 PR 合并的完整协作流程OceanBase 开源贡献指南从 Fork 到 PR 合并的完整协作流程 OceanBase 是一个开源分布式数据库其社区欢迎开发者以多种方式参与共建。本数据库分布式数据库关系型数据库后端高可用参与 Argilla 开源贡献的完整指南从 Issue 报告、Fork 分支到 PR 合并的全流程实战参与 Argilla 开源贡献的完整指南从 Issue 报告、Fork 分支到 PR 合并的全流程实战 Argilla 是一个面向 AI 工程师与领域专家协作数据标注人工智能NLPMLOpsRAG终极Odometer源码贡献指南7步从Fork到PR的完整流程终极Odometer源码贡献指南7步从Fork到PR的完整流程 Odometer是一个轻量级的JavaScript和CSS库专门用于创建平滑的数字过渡动画效前端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考