尧图网站建设 
LogicFlow 开源贡献指南从 Issue 提报到代码提交、测试与版本发布的完整工作流【免费下载链接】LogicFlowA flow chart editing framework focus on business customization. 专注于业务自定义的流程图编辑框架支持实现脑图、ER图、UML、工作流等各种图编辑场景。项目地址: https://gitcode.com/GitHub_Trending/lo/LogicFlowLogicFlow 是一个专注于业务自定义的流程图编辑框架代码库以 pnpm workspace 组织包含logicflow/core、logicflow/extension、logicflow/layout、logicflow/engine等多个核心包。本文以仓库根目录的 CONTRUBUTING.en-US.md 贡献指南为骨架结合根 package.json 的脚本体系、jest.config.ts 测试配置、husky 钩子与 scripts/publish-prerelease.mjs 发布脚本完整讲解外部贡献者如何报告 Issue、搭建本地开发环境、提交符合规范的 PR以及维护者如何基于 semver 进行分支管理与版本发布。读完后你将掌握一套可直接照做的 LogicFlow 贡献全流程。贡献方式概览LogicFlow 欢迎两种形式的参与报告 Issue发现 Bug、提出功能建议或文档疑问提交 PR直接改进代码、修复问题或实现新功能。无论是哪种方式逻辑都是一致的先明确意图再检索已有内容避免重复最后用规范的结构提交信息。报告新 Issue提交 Issue 前请遵守以下三条原则明确类型说清楚这是一个 Bug、功能需求Feature Request还是文档问题先检索后提报提交前搜索现有 Issue确保不会打开重复条目意图显式化在标签labels、标题title或内容content中清楚表达目的。仓库中的 CONTRIBUTING.md中文版与 CONTRUBUTING.en-US.md 都强调LogicFlow 维护组成员收到 Issue 后会确认其意图替换更准确的标签、关联 milestone并指派开发者跟进。本地开发环境搭建LogicFlow 仓库采用 pnpm workspace 管理多包根 package.json 中通过packageManager: pnpm9.4.0与engines: { node: 16.0.0, pnpm: 9.0.0 }声明了环境要求并配置了preinstall: npx only-allow pnpm——用其他包管理器安装会被直接拦截。工作区范围定义在 pnpm-workspace.yamlpackages: - packages/** - examples/** - sites/** - scripts即所有源码包packages/**、示例工程examples/**、文档站点sites/**与脚本目录都在同一 workspace 内。安装依赖$ pnpm install启动开发监听在子包源码改动时需要热更新其es/lib产物供示例工程引用。根脚本dev: pnpm -r --parallel --filter./packages/* run dev会并行监听所有包文档建议按如下方式分别操作$ cd packages/core # 或其他包例如 packages/extension $ pnpm run dev以 packages/core/package.json 为例其dev脚本实际指向rss复用根 package.json 中rss.dev的共享定义run-p -s build:less dev:esm dev:cjs即同时以 watch 模式编译 ESMtsc --module esnext --outDir ./es与 CJStsc --module commonjs --outDir ./lib产物。也可以直接在根目录执行pnpm run dev或pnpm start完成同样的并行监听。启动示例工程另开一个终端启动功能示例用于在浏览器中验证改动$ cd examples/feature-examples $ pnpm startexamples/feature-examples/package.json 中start即npm run dev底层为 umi dev其依赖全部通过workspace:*引用本地源码包因此可以实时看到对logicflow/core、logicflow/extension等的改动效果。如果你改动的是其他包如packages/extension、packages/layout进入对应的示例目录即可。开发分支规范从master切出开发分支分支名要有语义避免update、tmp这类无信息量命名$ git checkout -b branch-name文档明确建议如果改动是实现新功能使用feature/xxx前缀命名分支。这与发布策略中的分支管理保持一致见下文分支策略。测试提交前的必要关卡完成修改后必须运行测试$ pnpm run test根 package.json 中test: jest测试配置见 jest.config.ts使用ts-jest转换 TypeScriptbabel-jest转换 JS测试环境为jest-environment-jsdom通过moduleNameMapper将logicflow/core、logicflow/extension映射到对应包的src入口保证测试跑的是源码而非构建产物忽略node_modules、构建产物目录/es/、/lib/以及examples/vue3-app/通过 jest.setup.ts 在每条用例前完成测试框架初始化。仓库内置了大量与改动类型对应的测试用例可作为我应该为改动补什么测试的参照核心包测试packages/core/tests下按algorithm、event、history、model、util等模块划分例如model/grid-options.test.ts覆盖网格配置、bugs/1545-spec.test.ts覆盖历史 Bug 回归扩展包测试packages/extension/test下包含dynamic-group、bpmn-adapter、pool等模块的专项测试如dynamic-group/membership.test.ts、dynamic-group/resize-bounds.test.ts布局包测试packages/layout/test/group-layout.test.ts。如果现有测试不足以覆盖你的改动请新增用例或修改旧用例确保改动有据可查、后续不回归。代码风格检查贡献代码必须通过 ESLint 检查本地运行$ pnpm run lint:ts根 package.json 中该脚本定义为eslint **/src/**/*.{js,ts}?(x) --cache --fix即对全部源码包与示例的src目录做 lint 并自动修复。仓库还通过 husky 在提交前强制把关.husky/pre-commit 执行npx lint-staged根 package.json 的lint-staged配置对*.ts?(x)执行eslint --fixprettier --parsertypescript --write对*.less执行stylelint修复对其他文件统一执行 prettier 格式化。因此本地 commit 时风格问题就会被拦截。提交与 PR测试通过后即可提交并推送$ git add . # git add -u 删除文件 $ git commit -m fix(role): role.use must xxx $ git push origin branch-name推送后在 LogicFlow 仓库创建 Pull Request。为了让维护者与未来的贡献者能够回溯上下文PR 中应包含以下四部分信息Need需求点要实现什么功能一般关联相关 IssueUpdating Reason升级原因与 Issue 不同简要说明为什么需要做这个修改及其逻辑Related Testing相关测试说明与本次改动相关的测试部分User Tips用户提示如果 PR 涉及 API 变更或潜在兼容性问题必须给出对 LogicFlow 用户的提示否则可省略。Commit Message 规范LogicFlow 采用 Angular commit-message-format以获得可追踪的历史记录并自动生成 changelog。格式如下type(scope): subject BLANK LINE body BLANK LINE footertype必填九种类型type含义feat新功能fix修复 Bugdocs仅文档改动style不影响代码含义的格式改动空白、格式、缺失分号等refactor既非修复 Bug 也非新增功能的代码重构perf提升性能的改动test补充缺失的测试chore构建过程或辅助工具如文档生成的改动deps依赖更新scope可选描述改动所在的位置可以是包名如core、extension、模块或任意能指明改动范围的内容。subject必填用一句话简洁描述本次提交做了什么。body可选当 subject 不足以自解释时补充内容例如改动的目的与原因。footer可选Breaking Change 必须在此处明确说明关联相关 Issue如Closes #1, Closes #2, #3。完整示例fix($compile): [BREAKING_CHANGE] couple of unit tests for IE9 Older IEs serialize html uppercased, but IE9 does not... Would be better to expect case insensitive, unfortunately jasmine does not allow to user regexps for throw expectations. Document change on logicflow/core#12 Closes #392 BREAKING CHANGE: Breaks foo.bar api, foo.baz should be used instead值得一提的是规范并非只停留在文档层面根 package.json 配置了commitlint并extendscommitlint/config-conventional.husky/commit-msg 钩子会在每次 commit 时执行npx --no -- commitlint --edit ${1}。也就是说不符合 Conventional Commits 格式的提交信息在本地就会被拒绝与文档要求的 Angular 格式形成了代码级的强制闭环。另外根 lerna.json 中command: { version: { conventionalCommits: true } }表明版本号提升依赖 conventional commits 自动推导规范的提交信息会直接影响最终发布的版本号变化。发布管理LogicFlow 基于 semver 语义化版本进行发布。分支策略master分支始终是最新稳定版本所有开发直接从master切出分支进行所有 API 的废弃都需要在当前稳定版本上给出deprecated提示并保证在当前稳定版本上一直兼容到新版本发布。发布策略每个稳定版本的发布由一名负责人PM牵头在不同阶段承担不同职责准备阶段Preparation建立 milestone确认需求request与 milestone 的关联。发布前Before Release确认性能测试通过且当前 Milestone 内的所有 Issue 要么已关闭、要么可延期到后续版本发起 Release Proposal参照 node CHANGELOG 编写History并同步修正文档中与发布版本相关的内容提名下一稳定版本的负责人。发布时Releasing将旧稳定版本master备份到以当前大版本命名的分支如1.x并设置 tag 为{v}.xv为当前版本例如1.x将新稳定版本发布到 npm并通知上层框架更新npm publish之前请先阅读《How I publish an npm package》。实际发布脚本源码佐证发布流程在仓库中有完整的脚本化实现可参见 scripts/publish-prerelease.mjs 与根 package.json 的相关脚本Prerelease预发布/内测版$ pnpm publish:pre # 默认 tag alpha $ pnpm publish:pre beta # 发布 beta 包publish:pre脚本内部自动完成测试 → 构建含 UMD→ 生成快照版本号 → 发布到 npm → 还原 package.json的完整链路run(pnpm test) run(pnpm build) run(pnpm build:umd) run(pnpm changeset version --snapshot ${tag}) run(pnpm changeset publish --tag ${tag} --registry${registry})其设计要点与中文版 CONTRIBUTING.md 的发布流程一节一致快照版本形如2.3.0-alpha-20260705-abc123不会消费.changeset/*.md文件因此 changeset 会持续累积直到正式发布时一次性消费并生成完整 CHANGELOG发布结束后在finally块中执行git checkout -- packages/*/package.json还原版本号快照版本永远不会被提交。Stable Release对外正式发布$ pnpm changeset version # 消费累积的 changeset生成完整 CHANGELOG更新版本号 $ git add . git commit -m chore: version packages $ pnpm publish:only # 先跑测试再发布到 npm根 package.json 中publish:only: pnpm test changeset publish --registryhttps://registry.npmjs.org发布前会自动执行全量测试作为最后一道质量闸门。小结一条完整的 LogicFlow 贡献链路可以概括为提 Issue明确类型、检索去重、标注意图搭环境pnpm install→ 子包pnpm run dev监听产物 → 示例工程pnpm start实时验证建分支从master切出语义化命名分支新功能用feature/xxx改代码遵循仓库编码风格必要时补充测试测试体系见 jest.config.ts 与各包__tests__目录过质检pnpm run lint:ts通过 ESLintpnpm run test全量测试通过写提交按 Angular 格式书写commitlint 钩子.husky/commit-msg与 lint-staged.husky/pre-commit本地强制把关提 PR附上需求点、升级原因、相关测试与用户提示四要素发版本维护者基于 semver从master切分支用pnpm publish:pre发布 alpha/beta 快照用changeset versionpnpm publish:only发布正式版。这套从 Issue 到发布的工作流既保证了多包仓库core/extension/layout/engine的工程质量也让外部贡献者能够以最低成本、最高确定性参与到 LogicFlow 的迭代中。【免费下载链接】LogicFlowA flow chart editing framework focus on business customization. 专注于业务自定义的流程图编辑框架支持实现脑图、ER图、UML、工作流等各种图编辑场景。项目地址: https://gitcode.com/GitHub_Trending/lo/LogicFlow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 LogicFlow 开源贡献指南：从 Issue 提报到代码提交、测试与版本发布的完整工作流
LogicFlow 开源贡献指南从 Issue 提报到代码提交、测试与版本发布的完整工作流【免费下载链接】LogicFlowA flow chart editing framework focus on business customization. 专注于业务自定义的流程图编辑框架支持实现脑图、ER图、UML、工作流等各种图编辑场景。项目地址: https://gitcode.com/GitHub_Trending/lo/LogicFlowLogicFlow 是一个专注于业务自定义的流程图编辑框架代码库以 pnpm workspace 组织包含logicflow/core、logicflow/extension、logicflow/layout、logicflow/engine等多个核心包。本文以仓库根目录的 CONTRUBUTING.en-US.md 贡献指南为骨架结合根 package.json 的脚本体系、jest.config.ts 测试配置、husky 钩子与 scripts/publish-prerelease.mjs 发布脚本完整讲解外部贡献者如何报告 Issue、搭建本地开发环境、提交符合规范的 PR以及维护者如何基于 semver 进行分支管理与版本发布。读完后你将掌握一套可直接照做的 LogicFlow 贡献全流程。贡献方式概览LogicFlow 欢迎两种形式的参与报告 Issue发现 Bug、提出功能建议或文档疑问提交 PR直接改进代码、修复问题或实现新功能。无论是哪种方式逻辑都是一致的先明确意图再检索已有内容避免重复最后用规范的结构提交信息。报告新 Issue提交 Issue 前请遵守以下三条原则明确类型说清楚这是一个 Bug、功能需求Feature Request还是文档问题先检索后提报提交前搜索现有 Issue确保不会打开重复条目意图显式化在标签labels、标题title或内容content中清楚表达目的。仓库中的 CONTRIBUTING.md中文版与 CONTRUBUTING.en-US.md 都强调LogicFlow 维护组成员收到 Issue 后会确认其意图替换更准确的标签、关联 milestone并指派开发者跟进。本地开发环境搭建LogicFlow 仓库采用 pnpm workspace 管理多包根 package.json 中通过packageManager: pnpm9.4.0与engines: { node: 16.0.0, pnpm: 9.0.0 }声明了环境要求并配置了preinstall: npx only-allow pnpm——用其他包管理器安装会被直接拦截。工作区范围定义在 pnpm-workspace.yamlpackages: - packages/** - examples/** - sites/** - scripts即所有源码包packages/**、示例工程examples/**、文档站点sites/**与脚本目录都在同一 workspace 内。安装依赖$ pnpm install启动开发监听在子包源码改动时需要热更新其es/lib产物供示例工程引用。根脚本dev: pnpm -r --parallel --filter./packages/* run dev会并行监听所有包文档建议按如下方式分别操作$ cd packages/core # 或其他包例如 packages/extension $ pnpm run dev以 packages/core/package.json 为例其dev脚本实际指向rss复用根 package.json 中rss.dev的共享定义run-p -s build:less dev:esm dev:cjs即同时以 watch 模式编译 ESMtsc --module esnext --outDir ./es与 CJStsc --module commonjs --outDir ./lib产物。也可以直接在根目录执行pnpm run dev或pnpm start完成同样的并行监听。启动示例工程另开一个终端启动功能示例用于在浏览器中验证改动$ cd examples/feature-examples $ pnpm startexamples/feature-examples/package.json 中start即npm run dev底层为 umi dev其依赖全部通过workspace:*引用本地源码包因此可以实时看到对logicflow/core、logicflow/extension等的改动效果。如果你改动的是其他包如packages/extension、packages/layout进入对应的示例目录即可。开发分支规范从master切出开发分支分支名要有语义避免update、tmp这类无信息量命名$ git checkout -b branch-name文档明确建议如果改动是实现新功能使用feature/xxx前缀命名分支。这与发布策略中的分支管理保持一致见下文分支策略。测试提交前的必要关卡完成修改后必须运行测试$ pnpm run test根 package.json 中test: jest测试配置见 jest.config.ts使用ts-jest转换 TypeScriptbabel-jest转换 JS测试环境为jest-environment-jsdom通过moduleNameMapper将logicflow/core、logicflow/extension映射到对应包的src入口保证测试跑的是源码而非构建产物忽略node_modules、构建产物目录/es/、/lib/以及examples/vue3-app/通过 jest.setup.ts 在每条用例前完成测试框架初始化。仓库内置了大量与改动类型对应的测试用例可作为我应该为改动补什么测试的参照核心包测试packages/core/tests下按algorithm、event、history、model、util等模块划分例如model/grid-options.test.ts覆盖网格配置、bugs/1545-spec.test.ts覆盖历史 Bug 回归扩展包测试packages/extension/test下包含dynamic-group、bpmn-adapter、pool等模块的专项测试如dynamic-group/membership.test.ts、dynamic-group/resize-bounds.test.ts布局包测试packages/layout/test/group-layout.test.ts。如果现有测试不足以覆盖你的改动请新增用例或修改旧用例确保改动有据可查、后续不回归。代码风格检查贡献代码必须通过 ESLint 检查本地运行$ pnpm run lint:ts根 package.json 中该脚本定义为eslint **/src/**/*.{js,ts}?(x) --cache --fix即对全部源码包与示例的src目录做 lint 并自动修复。仓库还通过 husky 在提交前强制把关.husky/pre-commit 执行npx lint-staged根 package.json 的lint-staged配置对*.ts?(x)执行eslint --fixprettier --parsertypescript --write对*.less执行stylelint修复对其他文件统一执行 prettier 格式化。因此本地 commit 时风格问题就会被拦截。提交与 PR测试通过后即可提交并推送$ git add . # git add -u 删除文件 $ git commit -m fix(role): role.use must xxx $ git push origin branch-name推送后在 LogicFlow 仓库创建 Pull Request。为了让维护者与未来的贡献者能够回溯上下文PR 中应包含以下四部分信息Need需求点要实现什么功能一般关联相关 IssueUpdating Reason升级原因与 Issue 不同简要说明为什么需要做这个修改及其逻辑Related Testing相关测试说明与本次改动相关的测试部分User Tips用户提示如果 PR 涉及 API 变更或潜在兼容性问题必须给出对 LogicFlow 用户的提示否则可省略。Commit Message 规范LogicFlow 采用 Angular commit-message-format以获得可追踪的历史记录并自动生成 changelog。格式如下type(scope): subject BLANK LINE body BLANK LINE footertype必填九种类型type含义feat新功能fix修复 Bugdocs仅文档改动style不影响代码含义的格式改动空白、格式、缺失分号等refactor既非修复 Bug 也非新增功能的代码重构perf提升性能的改动test补充缺失的测试chore构建过程或辅助工具如文档生成的改动deps依赖更新scope可选描述改动所在的位置可以是包名如core、extension、模块或任意能指明改动范围的内容。subject必填用一句话简洁描述本次提交做了什么。body可选当 subject 不足以自解释时补充内容例如改动的目的与原因。footer可选Breaking Change 必须在此处明确说明关联相关 Issue如Closes #1, Closes #2, #3。完整示例fix($compile): [BREAKING_CHANGE] couple of unit tests for IE9 Older IEs serialize html uppercased, but IE9 does not... Would be better to expect case insensitive, unfortunately jasmine does not allow to user regexps for throw expectations. Document change on logicflow/core#12 Closes #392 BREAKING CHANGE: Breaks foo.bar api, foo.baz should be used instead值得一提的是规范并非只停留在文档层面根 package.json 配置了commitlint并extendscommitlint/config-conventional.husky/commit-msg 钩子会在每次 commit 时执行npx --no -- commitlint --edit ${1}。也就是说不符合 Conventional Commits 格式的提交信息在本地就会被拒绝与文档要求的 Angular 格式形成了代码级的强制闭环。另外根 lerna.json 中command: { version: { conventionalCommits: true } }表明版本号提升依赖 conventional commits 自动推导规范的提交信息会直接影响最终发布的版本号变化。发布管理LogicFlow 基于 semver 语义化版本进行发布。分支策略master分支始终是最新稳定版本所有开发直接从master切出分支进行所有 API 的废弃都需要在当前稳定版本上给出deprecated提示并保证在当前稳定版本上一直兼容到新版本发布。发布策略每个稳定版本的发布由一名负责人PM牵头在不同阶段承担不同职责准备阶段Preparation建立 milestone确认需求request与 milestone 的关联。发布前Before Release确认性能测试通过且当前 Milestone 内的所有 Issue 要么已关闭、要么可延期到后续版本发起 Release Proposal参照 node CHANGELOG 编写History并同步修正文档中与发布版本相关的内容提名下一稳定版本的负责人。发布时Releasing将旧稳定版本master备份到以当前大版本命名的分支如1.x并设置 tag 为{v}.xv为当前版本例如1.x将新稳定版本发布到 npm并通知上层框架更新npm publish之前请先阅读《How I publish an npm package》。实际发布脚本源码佐证发布流程在仓库中有完整的脚本化实现可参见 scripts/publish-prerelease.mjs 与根 package.json 的相关脚本Prerelease预发布/内测版$ pnpm publish:pre # 默认 tag alpha $ pnpm publish:pre beta # 发布 beta 包publish:pre脚本内部自动完成测试 → 构建含 UMD→ 生成快照版本号 → 发布到 npm → 还原 package.json的完整链路run(pnpm test) run(pnpm build) run(pnpm build:umd) run(pnpm changeset version --snapshot ${tag}) run(pnpm changeset publish --tag ${tag} --registry${registry})其设计要点与中文版 CONTRIBUTING.md 的发布流程一节一致快照版本形如2.3.0-alpha-20260705-abc123不会消费.changeset/*.md文件因此 changeset 会持续累积直到正式发布时一次性消费并生成完整 CHANGELOG发布结束后在finally块中执行git checkout -- packages/*/package.json还原版本号快照版本永远不会被提交。Stable Release对外正式发布$ pnpm changeset version # 消费累积的 changeset生成完整 CHANGELOG更新版本号 $ git add . git commit -m chore: version packages $ pnpm publish:only # 先跑测试再发布到 npm根 package.json 中publish:only: pnpm test changeset publish --registryhttps://registry.npmjs.org发布前会自动执行全量测试作为最后一道质量闸门。小结一条完整的 LogicFlow 贡献链路可以概括为提 Issue明确类型、检索去重、标注意图搭环境pnpm install→ 子包pnpm run dev监听产物 → 示例工程pnpm start实时验证建分支从master切出语义化命名分支新功能用feature/xxx改代码遵循仓库编码风格必要时补充测试测试体系见 jest.config.ts 与各包__tests__目录过质检pnpm run lint:ts通过 ESLintpnpm run test全量测试通过写提交按 Angular 格式书写commitlint 钩子.husky/commit-msg与 lint-staged.husky/pre-commit本地强制把关提 PR附上需求点、升级原因、相关测试与用户提示四要素发版本维护者基于 semver从master切分支用pnpm publish:pre发布 alpha/beta 快照用changeset versionpnpm publish:only发布正式版。这套从 Issue 到发布的工作流既保证了多包仓库core/extension/layout/engine的工程质量也让外部贡献者能够以最低成本、最高确定性参与到 LogicFlow 的迭代中。【免费下载链接】LogicFlowA flow chart editing framework focus on business customization. 专注于业务自定义的流程图编辑框架支持实现脑图、ER图、UML、工作流等各种图编辑场景。项目地址: https://gitcode.com/GitHub_Trending/lo/LogicFlow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考