前端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 仓库、按规范创建分支、遵循代码风格提交代码到发起符合 Conventional Commits 规范的 Pull Request、通过多轮 Review 完成合并再到同步上游变更与本地构建/测试/文档开发。读完本文你将掌握一套可直接上手操作的 Formily 贡献工作流并能结合仓库源码理解其 monorepo 工程约束yarn workspaces lerna jest commitlint使你的第一次 PR 顺畅通过审核。为什么成为 Formily 的贡献者Formily 是阿里巴巴唯一官方向外公布的开源表单框架功能和质量都有一定保证社区使用者众多。参与贡献不仅能让 Formily 变得更强大也能让更多开发者享受到更好的表单开发体验。项目维护团队非常感谢任何向本项目发起 Pull Request 的同学。无论你擅长内核逻辑、UI 组件还是文档写作都能在 Formily 社区找到适合自己的贡献方向。关于项目背景与快速上手可先阅读 docs/guide/index.md 与 docs/guide/quick-start.md。贡献范围你能做些什么Formily 的贡献类型非常宽泛官方文档将贡献内容划分为五类贡献类型具体内容features新增 / 修改功能特性unitest新增 / 修改单元测试bugfix修复现有 issue 中的问题doc文档改进other其他如示例、构建脚本、性能优化等其中「单测」在 Formily 中被视为与功能特性同等重要的贡献方向——这与仓库的工程质量体系直接相关根目录 jest.config.js 中collectCoverage: true表明仓库默认开启覆盖率统计新增功能若没有对应的单测覆盖将很难通过审核详见下文「PR 规范」。端到端贡献流程第一步Fork 并克隆仓库Formily 采用典型的 GitHub Fork 协作模型访问原始仓库alibaba/formily点击 Fork 按钮将仓库复制到你自己的 GitHub 账号下即目标仓库。将 fork 后的仓库克隆到本地并进入项目目录$ git clone 你的 fork 仓库地址 $ cd formily第二步按规范创建分支原始仓库的默认分支是master对应 alibaba/formily master你 fork 后本地开发不应直接改master而应基于它创建功能分支。官方建议的分支命名规则为[feat]-[name][feat]是分支类型可选值为feat功能、unitest单测、docs文档、bugfix缺陷修复、other其他[name]是分支名字自定义即可。示例分支名unittest-core的含义是「对核心包补充单测」$ git checkout -b unittest-core master分支命名与 PR 的 type 前缀保持一致的命名习惯能让维护者在 Pull Request 列表里一眼识别改动意图。第三步提交代码与代码风格开发完成后先在你 fork 出的仓库本地提交再推送并发起 Pull Request。Formily 对代码风格有两条硬性要求2 空格缩进不使用分号除非有明确说明代码中不得附带任何 console 相关方法及 debugger。这两条规范并非空谈仓库工程层已通过工具强制落地根目录 package.json 的lint-staged配置会在 pre-commit 阶段对*.{ts,tsx,js}依次执行eslint与pretty-quickprettier 的暂存文件格式化器对*.md执行pretty-quick。而devDependencies中同时引入了eslint-config-prettier说明 ESLint 规则与 prettier 格式化风格无分号、双空格是收敛一致的。也就是说只要本地跑通yarn lint提交的代码风格基本就能满足仓库要求。$ git add 改动文件 $ git commit -m feat(core): add unit test $ git push origin unittest-core第四步发起 Pull Request推送分支后在你 fork 的仓库页面向原始仓库发起 Pull Request。需要特别注意 PR 界面的目标指向左侧base repository必须是原始仓库alibaba/formily的master分支右侧head repository是你 fork 仓库的当前功能分支。官方提示左侧是目标仓库base repository 为 alibaba/formily master右侧是当前分支所在你 fork 的仓库两者切勿选反。第五步审核与合并Formily 的审核采用多轮 Review 流程janryWang负责最终裁决该改动是否合并其他维护者与社区成员也会在 PR 中参与讨论讨论记录完整保存在 PR 页面中钉钉群会同步收到相应通知。当 Pull Requests 列表中的该 PR 状态变为Closed时即表示合并成功。PR 与 Commit Message 规范Formily 要求 PR 名称遵循type(scope): subject格式例如feat(core): add unit test除了名称格式还有三条硬性要求维度要求PR 内容在描述中列举本次改动的内容PR 要求新增功能注释尽量清晰对应的单测覆盖要尽可能覆盖BUGFIX 要求若修复内容与 issues 相关请在 PR 内容中附上相关的 issueID其中「注释清晰 单测覆盖」与仓库质量体系一一对应Formily 的核心包 packages/core/src/tests下已沉淀了field.spec.ts、form.spec.ts、effects.spec.ts、lifecycle.spec.ts、array.spec.ts等 11 个测试文件新增功能参照这些既有用例编写测试是最稳妥的方式。Commit Message 同样被工程化约束根目录 commitlint.config.js 通过extends: [commitlint/config-conventional]强制提交信息遵循 Conventional Commits 规范且根 package.json 的 ghooks 配置中commit-msg钩子会执行commitlint --edit——也就是说Commit 信息不符合type(scope): subject格式将无法提交成功这一约束从源头保证了 PR 名称与提交历史的规范性。保持 Fork 与上游同步PR 合并或社区有新提交后你需要定期把原始仓库的最新变更同步到 fork 仓库避免功能分支与上游 master 产生过多冲突。官方给出的同步流程如下# 1. 为本地仓库添加 upstream即原始仓库 $ git remote add upstream 原始仓库地址 # 2. 获取原始仓库的最新变更 $ git fetch upstream # 3. 将原始仓库的改动同步到本地目标分支不指定分支名时默认同步到当前分支 $ git pull upstream master同步完成后再推送回你自己的 fork 仓库git push origin 分支名即可基于最新代码继续开发或更新 PR。本地开发构建、测试与 LintFormily 是一个典型的多包 monorepo根目录 package.json 的workspaces字段声明了packages/*与devtools/*两个工作区lerna.json 中useWorkspaces: true、npmClient: yarn因此推荐使用yarn 1.x进行包管理与跨包脚本编排。安装依赖$ cd formily $ yarn install # 安装整体项目依赖构建所有项目$ yarn build # 构建所有项目build脚本的真实定义为rimraf -rf packages/*/{lib,dist,esm} lerna run build先清理所有子包的历史产物lib / dist / esm再通过 lerna 并行触发各子包的构建。以 packages/core/package.json 为例单个子包的构建包含build:cjstsc 编译 CommonJS 到 lib、build:esmtsc 编译 ES Module 到 esm与build:umdrollup 打包 UMD 到 dist三个阶段。执行单元测试$ yarn test # 执行单元测试test脚本实际运行jest --coverage。结合 jest.config.js 可以看到仓库的测试约定preset: ts-jest直接对 TypeScript 源码运行测试testMatch: [**/__tests__/**/*.spec.[jt]s?(x)]测试文件统一放在各包的__tests__目录、以.spec.ts(x)命名如packages/core/src/__tests__/field.spec.tstestEnvironment: jsdom可在 Node 环境模拟 DOMsetupFilesAfterEnv引入 global.config.ts为所有用例注入sleep、requestAnimationFrame等全局辅助函数collectCoverage: true默认开启覆盖率统计。当只需验证某个子包时仓库还提供了细粒度的测试脚本例如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等对应jest packages/pkg/的定向执行调试时可使用yarn test:core:watch进入 watch 模式。Lint 与代码格式化$ yarn lint # 执行 eslint .ESLint 覆盖.ts/.tsx/.js与 Markdown 文档配合 prettier 实现风格统一。提交前建议本地依次跑yarn lint、yarn test与yarn build确保 CI 与 pre-commit 钩子lint-staged不会拦截你的提交。文档站开发Formily 的文档站基于 dumi 构建根 package.json 的start脚本为dumi devbuild:docs为dumi build因此文档类贡献可以直接在本地实时预览# 主项目文档docs/ 目录 $ yarn start # 内核项目文档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/目录下维护独立文档例如 packages/core/docs/guide 中的架构、字段、表单与 MVVM 讲解以及 packages/react/docs、packages/vue/docs 的 API 文档。本文所依据的贡献指南也有对应的中文版本 docs/guide/contribution.zh-CN.md文档类贡献者可以对照中英版本进行改进。Monorepo 结构速览源码佐证理解仓库结构能帮助你快速定位改动所在包。从各子包 package.json 的name字段可以看到 Formily 当前的主要工作区成员子包定位formily/core表单内核字段、生命周期、状态机formily/react / formily/vueReact / Vue 适配层formily/antd / formily/next / formily/elementAnt Design / Fusion Next / Element 组件库formily/reactive / formily/reactive-react / formily/reactive-vue响应式模型与框架桥接formily/json-schema / formily/validator / formily/path / formily/shared / formily/gridJSON Schema 编译、校验、路径解析、共享工具等基础能力跨包开发时根目录 tsconfig.json 的paths将formily/*映射到各包的src目录保证 monorepo 内部以源码形态互相引用、调试所见即所得。总结向 Formily 贡献代码的完整链路可以概括为Fork 仓库 → 按类型-名称规则建分支 → 遵循「2 空格、无分号、无 console/debugger」风格开发 → 以type(scope): subject格式提交并发起 PR → 补充清晰注释与单测覆盖 → 通过多轮 Review 后合并 → 定期用 upstream 同步上游变更。整个流程中commitlint、lint-staged、jest 覆盖率与 lerna 多包构建共同构成了质量闸门理解这些工程约束不仅能让你的 PR 一次通过也能让你更深入地理解 Formily 的协作方式与代码组织哲学。赞分享前端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点击查看免费下载相关推荐MMPose 开源贡献指南从 Fork 到合入的完整 PR 流程与代码规范实战MMPose 开源贡献指南从 Fork 到合入的完整 PR 流程与代码规范实战 导读 本文基于 MMPose 官方中文贡献指南结合仓库内真实的 CI 工作流计算机视觉人工智能深度学习Flower 贡献工作流实战从 Fork 仓库到合并第一个 PR 的完整指南Flower 贡献工作流实战从 Fork 仓库到合并第一个 PR 的完整指南 本文基于 Flower 官方文档《Contribute on GitHub》整理人工智能联邦学习机器学习深度学习炉石传说 HsMod 插件指南3 步装完变速、开包、换皮肤全都有炉石传说 HsMod 插件指南3 步装完变速、开包、换皮肤全都有 开包开到手酸、过场动画磨人、界面千篇一律炉石传说插件 HsMod 一次接住这三件事它是AI AgentAgent 工作流开发工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 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 仓库、按规范创建分支、遵循代码风格提交代码到发起符合 Conventional Commits 规范的 Pull Request、通过多轮 Review 完成合并再到同步上游变更与本地构建/测试/文档开发。读完本文你将掌握一套可直接上手操作的 Formily 贡献工作流并能结合仓库源码理解其 monorepo 工程约束yarn workspaces lerna jest commitlint使你的第一次 PR 顺畅通过审核。为什么成为 Formily 的贡献者Formily 是阿里巴巴唯一官方向外公布的开源表单框架功能和质量都有一定保证社区使用者众多。参与贡献不仅能让 Formily 变得更强大也能让更多开发者享受到更好的表单开发体验。项目维护团队非常感谢任何向本项目发起 Pull Request 的同学。无论你擅长内核逻辑、UI 组件还是文档写作都能在 Formily 社区找到适合自己的贡献方向。关于项目背景与快速上手可先阅读 docs/guide/index.md 与 docs/guide/quick-start.md。贡献范围你能做些什么Formily 的贡献类型非常宽泛官方文档将贡献内容划分为五类贡献类型具体内容features新增 / 修改功能特性unitest新增 / 修改单元测试bugfix修复现有 issue 中的问题doc文档改进other其他如示例、构建脚本、性能优化等其中「单测」在 Formily 中被视为与功能特性同等重要的贡献方向——这与仓库的工程质量体系直接相关根目录 jest.config.js 中collectCoverage: true表明仓库默认开启覆盖率统计新增功能若没有对应的单测覆盖将很难通过审核详见下文「PR 规范」。端到端贡献流程第一步Fork 并克隆仓库Formily 采用典型的 GitHub Fork 协作模型访问原始仓库alibaba/formily点击 Fork 按钮将仓库复制到你自己的 GitHub 账号下即目标仓库。将 fork 后的仓库克隆到本地并进入项目目录$ git clone 你的 fork 仓库地址 $ cd formily第二步按规范创建分支原始仓库的默认分支是master对应 alibaba/formily master你 fork 后本地开发不应直接改master而应基于它创建功能分支。官方建议的分支命名规则为[feat]-[name][feat]是分支类型可选值为feat功能、unitest单测、docs文档、bugfix缺陷修复、other其他[name]是分支名字自定义即可。示例分支名unittest-core的含义是「对核心包补充单测」$ git checkout -b unittest-core master分支命名与 PR 的 type 前缀保持一致的命名习惯能让维护者在 Pull Request 列表里一眼识别改动意图。第三步提交代码与代码风格开发完成后先在你 fork 出的仓库本地提交再推送并发起 Pull Request。Formily 对代码风格有两条硬性要求2 空格缩进不使用分号除非有明确说明代码中不得附带任何 console 相关方法及 debugger。这两条规范并非空谈仓库工程层已通过工具强制落地根目录 package.json 的lint-staged配置会在 pre-commit 阶段对*.{ts,tsx,js}依次执行eslint与pretty-quickprettier 的暂存文件格式化器对*.md执行pretty-quick。而devDependencies中同时引入了eslint-config-prettier说明 ESLint 规则与 prettier 格式化风格无分号、双空格是收敛一致的。也就是说只要本地跑通yarn lint提交的代码风格基本就能满足仓库要求。$ git add 改动文件 $ git commit -m feat(core): add unit test $ git push origin unittest-core第四步发起 Pull Request推送分支后在你 fork 的仓库页面向原始仓库发起 Pull Request。需要特别注意 PR 界面的目标指向左侧base repository必须是原始仓库alibaba/formily的master分支右侧head repository是你 fork 仓库的当前功能分支。官方提示左侧是目标仓库base repository 为 alibaba/formily master右侧是当前分支所在你 fork 的仓库两者切勿选反。第五步审核与合并Formily 的审核采用多轮 Review 流程janryWang负责最终裁决该改动是否合并其他维护者与社区成员也会在 PR 中参与讨论讨论记录完整保存在 PR 页面中钉钉群会同步收到相应通知。当 Pull Requests 列表中的该 PR 状态变为Closed时即表示合并成功。PR 与 Commit Message 规范Formily 要求 PR 名称遵循type(scope): subject格式例如feat(core): add unit test除了名称格式还有三条硬性要求维度要求PR 内容在描述中列举本次改动的内容PR 要求新增功能注释尽量清晰对应的单测覆盖要尽可能覆盖BUGFIX 要求若修复内容与 issues 相关请在 PR 内容中附上相关的 issueID其中「注释清晰 单测覆盖」与仓库质量体系一一对应Formily 的核心包 packages/core/src/tests下已沉淀了field.spec.ts、form.spec.ts、effects.spec.ts、lifecycle.spec.ts、array.spec.ts等 11 个测试文件新增功能参照这些既有用例编写测试是最稳妥的方式。Commit Message 同样被工程化约束根目录 commitlint.config.js 通过extends: [commitlint/config-conventional]强制提交信息遵循 Conventional Commits 规范且根 package.json 的 ghooks 配置中commit-msg钩子会执行commitlint --edit——也就是说Commit 信息不符合type(scope): subject格式将无法提交成功这一约束从源头保证了 PR 名称与提交历史的规范性。保持 Fork 与上游同步PR 合并或社区有新提交后你需要定期把原始仓库的最新变更同步到 fork 仓库避免功能分支与上游 master 产生过多冲突。官方给出的同步流程如下# 1. 为本地仓库添加 upstream即原始仓库 $ git remote add upstream 原始仓库地址 # 2. 获取原始仓库的最新变更 $ git fetch upstream # 3. 将原始仓库的改动同步到本地目标分支不指定分支名时默认同步到当前分支 $ git pull upstream master同步完成后再推送回你自己的 fork 仓库git push origin 分支名即可基于最新代码继续开发或更新 PR。本地开发构建、测试与 LintFormily 是一个典型的多包 monorepo根目录 package.json 的workspaces字段声明了packages/*与devtools/*两个工作区lerna.json 中useWorkspaces: true、npmClient: yarn因此推荐使用yarn 1.x进行包管理与跨包脚本编排。安装依赖$ cd formily $ yarn install # 安装整体项目依赖构建所有项目$ yarn build # 构建所有项目build脚本的真实定义为rimraf -rf packages/*/{lib,dist,esm} lerna run build先清理所有子包的历史产物lib / dist / esm再通过 lerna 并行触发各子包的构建。以 packages/core/package.json 为例单个子包的构建包含build:cjstsc 编译 CommonJS 到 lib、build:esmtsc 编译 ES Module 到 esm与build:umdrollup 打包 UMD 到 dist三个阶段。执行单元测试$ yarn test # 执行单元测试test脚本实际运行jest --coverage。结合 jest.config.js 可以看到仓库的测试约定preset: ts-jest直接对 TypeScript 源码运行测试testMatch: [**/__tests__/**/*.spec.[jt]s?(x)]测试文件统一放在各包的__tests__目录、以.spec.ts(x)命名如packages/core/src/__tests__/field.spec.tstestEnvironment: jsdom可在 Node 环境模拟 DOMsetupFilesAfterEnv引入 global.config.ts为所有用例注入sleep、requestAnimationFrame等全局辅助函数collectCoverage: true默认开启覆盖率统计。当只需验证某个子包时仓库还提供了细粒度的测试脚本例如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等对应jest packages/pkg/的定向执行调试时可使用yarn test:core:watch进入 watch 模式。Lint 与代码格式化$ yarn lint # 执行 eslint .ESLint 覆盖.ts/.tsx/.js与 Markdown 文档配合 prettier 实现风格统一。提交前建议本地依次跑yarn lint、yarn test与yarn build确保 CI 与 pre-commit 钩子lint-staged不会拦截你的提交。文档站开发Formily 的文档站基于 dumi 构建根 package.json 的start脚本为dumi devbuild:docs为dumi build因此文档类贡献可以直接在本地实时预览# 主项目文档docs/ 目录 $ yarn start # 内核项目文档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/目录下维护独立文档例如 packages/core/docs/guide 中的架构、字段、表单与 MVVM 讲解以及 packages/react/docs、packages/vue/docs 的 API 文档。本文所依据的贡献指南也有对应的中文版本 docs/guide/contribution.zh-CN.md文档类贡献者可以对照中英版本进行改进。Monorepo 结构速览源码佐证理解仓库结构能帮助你快速定位改动所在包。从各子包 package.json 的name字段可以看到 Formily 当前的主要工作区成员子包定位formily/core表单内核字段、生命周期、状态机formily/react / formily/vueReact / Vue 适配层formily/antd / formily/next / formily/elementAnt Design / Fusion Next / Element 组件库formily/reactive / formily/reactive-react / formily/reactive-vue响应式模型与框架桥接formily/json-schema / formily/validator / formily/path / formily/shared / formily/gridJSON Schema 编译、校验、路径解析、共享工具等基础能力跨包开发时根目录 tsconfig.json 的paths将formily/*映射到各包的src目录保证 monorepo 内部以源码形态互相引用、调试所见即所得。总结向 Formily 贡献代码的完整链路可以概括为Fork 仓库 → 按类型-名称规则建分支 → 遵循「2 空格、无分号、无 console/debugger」风格开发 → 以type(scope): subject格式提交并发起 PR → 补充清晰注释与单测覆盖 → 通过多轮 Review 后合并 → 定期用 upstream 同步上游变更。整个流程中commitlint、lint-staged、jest 覆盖率与 lerna 多包构建共同构成了质量闸门理解这些工程约束不仅能让你的 PR 一次通过也能让你更深入地理解 Formily 的协作方式与代码组织哲学。赞分享前端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点击查看免费下载相关推荐MMPose 开源贡献指南从 Fork 到合入的完整 PR 流程与代码规范实战MMPose 开源贡献指南从 Fork 到合入的完整 PR 流程与代码规范实战 导读 本文基于 MMPose 官方中文贡献指南结合仓库内真实的 CI 工作流计算机视觉人工智能深度学习Flower 贡献工作流实战从 Fork 仓库到合并第一个 PR 的完整指南Flower 贡献工作流实战从 Fork 仓库到合并第一个 PR 的完整指南 本文基于 Flower 官方文档《Contribute on GitHub》整理人工智能联邦学习机器学习深度学习炉石传说 HsMod 插件指南3 步装完变速、开包、换皮肤全都有炉石传说 HsMod 插件指南3 步装完变速、开包、换皮肤全都有 开包开到手酸、过场动画磨人、界面千篇一律炉石传说插件 HsMod 一次接住这三件事它是AI AgentAgent 工作流开发工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考