lowcode-engine 研发协作流程代码风格、单元测试、分支模型与 Lerna 发布机制全解【免费下载链接】lowcode-engineAn enterprise-class low-code technology stack with scale-out design / 一套面向扩展设计的企业级低代码技术体系项目地址: https://gitcode.com/GitHub_Trending/lo/lowcode-engine本文为 lowcode-engine阿里低代码引擎官方文档「研发协作流程」的深度解读版。它系统梳理了引擎仓库在贡献代码时必须遵守的四类规范——代码风格检查、单元测试机制、commit 规范与分支模型并逐一还原正式版/多轮 beta 版/DEMO 的完整发布步骤。读完后你将掌握该仓库从npm run build到lerna publish的全链路研发协作流程并能结合根目录 package.json、lerna.json 与.github/workflows下的 CI/发布工作流理解每一项规范背后的工程实现。一、代码风格eslint / stylelint 前置检查严禁跳过引擎项目配置了 eslint 和 stylelint每次 git commit 前都会检查代码风格如有报错必须先修改再提交。官方文档特别强调严禁使用--no-verify-n跳过本地钩子提交——即使本地侥幸绕过了也逃脱不了 GitHub workflow 的 lint 检查。这一“本地 CI 双重拦截”并非空话仓库中有多处实现证据本地 husky 钩子根 package.json 中通过husky.hooks配置了两个钩子pre-commitf2elint commit-file-scan——对本次提交涉及的文件做 eslint/stylelint 扫描commit-msgf2elint commit-msg-scan——校验 commit message 是否符合规范。 也就是说-n跳过 pre-commit 后commit-msg 与后续 CI 仍会继续把关。CI 侧 lint 任务.github/workflows/test packages.yml 在packages/**排除.md发生 push 或 pull_request 时触发其中lintjob 会执行根目录的npm run lint其实际命令为f2elint scan -q -i ./packages/*/src见 package.json 的lint脚本。modules/**目录另有对应的lint:modules脚本f2elint scan -q -i ./modules/*/src由 test modules.yml 工作流负责。配套说明仓库对命名、类型定义、注释等细节另有成文约定可参考 编码规约如接口以I前缀命名、字符串使用单引号、共享类型放在types.ts等与 lint 规则互为补充。二、测试机制提交前必跑单测核心模块覆盖率 80%官方文档对测试的要求可以概括为三条每次提交代码前务必本地跑一次单元测试通过后再提交 MR涉及新功能需要补充相应的单元测试——目前引擎核心模块的单测覆盖率都在 80% 以上如果 PR 降低了覆盖率将不予通过单测文件按被测文件的目录结构放置见 编码规约。本地跑单测的标准流程项目根目录下执行构建npm run build对应脚本./scripts/build.sh只改了一个包如 designer进入该包目录执行npm test例如cd packages/designer npm test改了多个包直接在根目录执行npm test其实际命令是lerna run test --stream见 package.json会按 lerna 依赖顺序流式跑遍各包的测试。CI 如何印证这一机制test packages.yml 为每个核心包各配了一个独立 jobtest-designer、test-editor-skeleton、test-renderer-core、test-react-simulator-renderer、test-utils、test-editor-core、test-plugin-command均在npm i npm run setup:skip-build后于对应包目录执行npm testci.yml 则负责覆盖率对 designer、renderer-core、react-simulator-renderer、code-generator 四个模块执行npm run test:cov并把coverage/目录上传到 Codecovfail_ci_if_error: true。这正是“覆盖率下降不予通过”的自动执行载体——核心包的覆盖率数据持续可见、可对比。三、commit 风格Conventional Commits 一个改动一个 commit文档要求 commit message 遵循 Conventional Commits 规范即type(scope): description结构仓库中的落地配置有commitlint.config.jsextends: [ali]即采用阿里内部 f2elint 提供的 commitlint 规则集由 husky 的commit-msg钩子f2elint commit-msg-scan见 package.json在本地强制校验lerna.json 中command.publish配置了conventionalCommits: true与message: chore(release): publish %v。这也解释了文档中“changelog 也能自动生成”的说法从源码结构看lerna 在发布时会基于 Conventional Commits 历史生成变更日志发布 commit 本身也以chore(release): publish %v的规范格式写入版本信息。一个 bugfix / feature 对应一个 commit文档明确要求如果一个 MR 里混入了多个 bugfix/feature 或试验性 commit请先 rebase 整理后再提交 MR。文档给出的理由非常实在引擎整体的 commit 历史因此保持清晰每个 commit 完成一件确定的事假如某个 commit 引入了 bug可以很容易地通过rebase -idrop 等方式快速剔除而不必整体回滚。四、分支用途main / develop / release 三层模型文档定义的分支职责如下分支职责main最稳定的分支与 npmlatest标签的包内容保持一致develop开发分支拥有最新的、已验证过的 feature / bugfix是所有 Pull Request 的目标合入分支release/x.y.z正式发布分支一般从 develop 拉出x.y.z为待发布版本号release/x.y.z-beta(.N)beta 发布分支命名规则release/x.y.z-beta(\.\d)?用于快速验证修改并发布 npm beta 版本这个模型与 lerna.json 的command.version.allowBranch配置互相印证——lerna 只在master、main、release/*以及内部使用的daily/*、refactor/*分支上允许执行版本号变更操作从工具层面保证了版本号只能在这些受控分支上被推进。beta 分支合回 develop 有讲究由于 beta 发布分支上会存在无用的 commit例如 lerna 自动修改各包 package.json 版本号的提交因此不直接 PR 到 develop而是从 develop 拉一个新分支把 beta 分支上有用的 commitcherry-pick过去再 PR 到 develop。五、引擎发布机制日常迭代的节奏是从 develop 拉分支 → 自测、单测通过 → 提交 PR 到 develop → 由发布负责人基于 develop 拉release/1.0.z分支。版本规划此处是理想节奏实际情况可能会有调整。日常迭代 2 周一般月中或月底发版发版日两天前发最后一个 beta 版本原则上不再接受新 PR灰度 2 天后发正式版特殊情况紧急迭代随时发大 Feature 迭代每年 24 次。发正式版以 1.0.0 为例切到 developgit checkout develop创建 release 分支git checkout -b release/1.0.0构建npm run build发布到 npmnpm run pub从 package.json 看该脚本实际执行npm run watchdog:build lerna publish patch --yes --force-publish --exact --no-changelog——先经 watchdog 守护构建再强制全量发布、精确匹配版本号同步到 tnpm 源 alifd CDN uipaas CDNtnpm run sync、tnpm run syncOss。此步骤把已发布在 npm 源的包同步到内部源对应脚本./scripts/sync.sh与node ./scripts/sync-oss.js因为 alifd CDN 依赖内部 npm 源更新发布日志Releases合并release/x.x.x到main分支合并main分支到develop分支。发 beta 版本beta 分三种情形命令差异在发布子命令上情形 A发某 y 位版本首个 beta如1.1.0-beta.0git checkout develop git pull # 更新到最新如需 git checkout -b release/1.1.0-beta git push --set-upstream origin release/1.1.0-beta npm run build npm run pub:preminor # 需有 alilc scope 发包权限 tnpm run sync tnpm run syncOss其中pub:preminor对应lerna publish preminor --force-publish --exact --dist-tag beta --preid beta --no-changelog即次版本号 1 并打betadist-tag、beta预发布前缀。情形 B发某 z 位版本首个 beta如1.0.1-beta.0流程与情形 A 相同区别仅在分支名release/1.0.1-beta与发布命令npm run pub:prepatch # lerna publish prepatch ... --dist-tag beta --preid beta情形 C发某版本非首个 beta如1.0.1-beta.0→1.0.1-beta.1git checkout release/1.0.1-beta git rebase origin/develop # 更新到 develop 分支最新代码 npm run build npm run pub:prerelease # 注意与首个 beta 时命令不同 tnpm run sync tnpm run syncOsspub:prerelease对应lerna publish prerelease --yes ... --dist-tag beta --preid beta——只递增预发布序列号-beta.N的 N适合在同一 release 分支上多轮发 beta。GitHub Actions 中的自动发布工作流仓库的.github/workflows目录为上述流程提供了自动化通道值得留意两个细节publish engine beta.yml当向匹配release/[0-9].[0-9].[0-9]-beta的分支 push 且变更涉及packages/**时自动触发执行npm install npm run setup→npm run build→npm run pub:prerelease使用NODE_AUTH_TOKEN完成 npm 认证最后输出新版本号。这正是“推送到 beta 分支即自动发下一轮 beta”的落地方式publish engine.yml手动触发workflow_dispatch需填写要执行的 publish 命令且限定在release/开头的分支、并白名单了两位发布负责人账号Node 版本为 16执行npm run $publishCommand。此外文档提示发布需要权限如果提 PR 后着急发布可以加入贡献者交流群与发布负责人沟通。六、DEMO 发布机制DEMO 与引擎本体的发布路径不同流程更轻量修改版本号手动修改 deploy-space/package.json 等 DEMO 侧 package.json 的版本号buildnpm run buildpublish需要 npm 发包权限npm run pub # 如发 beta 版 npm publish --tag beta同步tnpm run sync与tnpm run syncOss把包同步到 tnpm 源 alifd CDN uipaas CDN。最后一步“官网生效”需要在内部系统中更新 demo 版本后线上页面才会切换到新构建产物。七、要点速查事项命令 / 规则仓库证据提交前 linthusky pre-commit/commit-msgf2elintpackage.json、commitlint.config.js本地构建npm run buildpackage.json单包测试cd packages/pkg npm testtest packages.yml全量测试npm testlerna run test --streampackage.json覆盖率门禁核心模块 80%Codecov 上传ci.yml发正式版npm run publerna publish patchpackage.json、lerna.json发首个 betanpm run pub:preminor/pub:prepatchpackage.json发后续 betanpm run pub:prerelease可被 beta 分支 push 自动触发publish engine beta.yml环境要求仓库engines声明node 14.17.0 18贡献文档推荐 Node.js 16package.json、参与贡献需要注意的适用前提文档中的tnpm run sync/syncOss属于阿里内部源同步步骤外部贡献者通常只执行到npm run pub之前PR 的目标分支应为 developlowcode-engine 仓库从 develop 建分支、PR 指向 develop详见参与贡献。整体来看这套协作流程以 husky 本地钩子兜住风格与 commit 规范、以分包 CI job Codecov 兜住测试与覆盖率、以 lerna allowBranch 分支白名单 GitHub Actions 兜住发布安全构成了一个可追溯、可回退、可自动化的研发协作闭环。【免费下载链接】lowcode-engineAn enterprise-class low-code technology stack with scale-out design / 一套面向扩展设计的企业级低代码技术体系项目地址: https://gitcode.com/GitHub_Trending/lo/lowcode-engine创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
lowcode-engine 研发协作流程：代码风格、单元测试、分支模型与 Lerna 发布机制全解
lowcode-engine 研发协作流程代码风格、单元测试、分支模型与 Lerna 发布机制全解【免费下载链接】lowcode-engineAn enterprise-class low-code technology stack with scale-out design / 一套面向扩展设计的企业级低代码技术体系项目地址: https://gitcode.com/GitHub_Trending/lo/lowcode-engine本文为 lowcode-engine阿里低代码引擎官方文档「研发协作流程」的深度解读版。它系统梳理了引擎仓库在贡献代码时必须遵守的四类规范——代码风格检查、单元测试机制、commit 规范与分支模型并逐一还原正式版/多轮 beta 版/DEMO 的完整发布步骤。读完后你将掌握该仓库从npm run build到lerna publish的全链路研发协作流程并能结合根目录 package.json、lerna.json 与.github/workflows下的 CI/发布工作流理解每一项规范背后的工程实现。一、代码风格eslint / stylelint 前置检查严禁跳过引擎项目配置了 eslint 和 stylelint每次 git commit 前都会检查代码风格如有报错必须先修改再提交。官方文档特别强调严禁使用--no-verify-n跳过本地钩子提交——即使本地侥幸绕过了也逃脱不了 GitHub workflow 的 lint 检查。这一“本地 CI 双重拦截”并非空话仓库中有多处实现证据本地 husky 钩子根 package.json 中通过husky.hooks配置了两个钩子pre-commitf2elint commit-file-scan——对本次提交涉及的文件做 eslint/stylelint 扫描commit-msgf2elint commit-msg-scan——校验 commit message 是否符合规范。 也就是说-n跳过 pre-commit 后commit-msg 与后续 CI 仍会继续把关。CI 侧 lint 任务.github/workflows/test packages.yml 在packages/**排除.md发生 push 或 pull_request 时触发其中lintjob 会执行根目录的npm run lint其实际命令为f2elint scan -q -i ./packages/*/src见 package.json 的lint脚本。modules/**目录另有对应的lint:modules脚本f2elint scan -q -i ./modules/*/src由 test modules.yml 工作流负责。配套说明仓库对命名、类型定义、注释等细节另有成文约定可参考 编码规约如接口以I前缀命名、字符串使用单引号、共享类型放在types.ts等与 lint 规则互为补充。二、测试机制提交前必跑单测核心模块覆盖率 80%官方文档对测试的要求可以概括为三条每次提交代码前务必本地跑一次单元测试通过后再提交 MR涉及新功能需要补充相应的单元测试——目前引擎核心模块的单测覆盖率都在 80% 以上如果 PR 降低了覆盖率将不予通过单测文件按被测文件的目录结构放置见 编码规约。本地跑单测的标准流程项目根目录下执行构建npm run build对应脚本./scripts/build.sh只改了一个包如 designer进入该包目录执行npm test例如cd packages/designer npm test改了多个包直接在根目录执行npm test其实际命令是lerna run test --stream见 package.json会按 lerna 依赖顺序流式跑遍各包的测试。CI 如何印证这一机制test packages.yml 为每个核心包各配了一个独立 jobtest-designer、test-editor-skeleton、test-renderer-core、test-react-simulator-renderer、test-utils、test-editor-core、test-plugin-command均在npm i npm run setup:skip-build后于对应包目录执行npm testci.yml 则负责覆盖率对 designer、renderer-core、react-simulator-renderer、code-generator 四个模块执行npm run test:cov并把coverage/目录上传到 Codecovfail_ci_if_error: true。这正是“覆盖率下降不予通过”的自动执行载体——核心包的覆盖率数据持续可见、可对比。三、commit 风格Conventional Commits 一个改动一个 commit文档要求 commit message 遵循 Conventional Commits 规范即type(scope): description结构仓库中的落地配置有commitlint.config.jsextends: [ali]即采用阿里内部 f2elint 提供的 commitlint 规则集由 husky 的commit-msg钩子f2elint commit-msg-scan见 package.json在本地强制校验lerna.json 中command.publish配置了conventionalCommits: true与message: chore(release): publish %v。这也解释了文档中“changelog 也能自动生成”的说法从源码结构看lerna 在发布时会基于 Conventional Commits 历史生成变更日志发布 commit 本身也以chore(release): publish %v的规范格式写入版本信息。一个 bugfix / feature 对应一个 commit文档明确要求如果一个 MR 里混入了多个 bugfix/feature 或试验性 commit请先 rebase 整理后再提交 MR。文档给出的理由非常实在引擎整体的 commit 历史因此保持清晰每个 commit 完成一件确定的事假如某个 commit 引入了 bug可以很容易地通过rebase -idrop 等方式快速剔除而不必整体回滚。四、分支用途main / develop / release 三层模型文档定义的分支职责如下分支职责main最稳定的分支与 npmlatest标签的包内容保持一致develop开发分支拥有最新的、已验证过的 feature / bugfix是所有 Pull Request 的目标合入分支release/x.y.z正式发布分支一般从 develop 拉出x.y.z为待发布版本号release/x.y.z-beta(.N)beta 发布分支命名规则release/x.y.z-beta(\.\d)?用于快速验证修改并发布 npm beta 版本这个模型与 lerna.json 的command.version.allowBranch配置互相印证——lerna 只在master、main、release/*以及内部使用的daily/*、refactor/*分支上允许执行版本号变更操作从工具层面保证了版本号只能在这些受控分支上被推进。beta 分支合回 develop 有讲究由于 beta 发布分支上会存在无用的 commit例如 lerna 自动修改各包 package.json 版本号的提交因此不直接 PR 到 develop而是从 develop 拉一个新分支把 beta 分支上有用的 commitcherry-pick过去再 PR 到 develop。五、引擎发布机制日常迭代的节奏是从 develop 拉分支 → 自测、单测通过 → 提交 PR 到 develop → 由发布负责人基于 develop 拉release/1.0.z分支。版本规划此处是理想节奏实际情况可能会有调整。日常迭代 2 周一般月中或月底发版发版日两天前发最后一个 beta 版本原则上不再接受新 PR灰度 2 天后发正式版特殊情况紧急迭代随时发大 Feature 迭代每年 24 次。发正式版以 1.0.0 为例切到 developgit checkout develop创建 release 分支git checkout -b release/1.0.0构建npm run build发布到 npmnpm run pub从 package.json 看该脚本实际执行npm run watchdog:build lerna publish patch --yes --force-publish --exact --no-changelog——先经 watchdog 守护构建再强制全量发布、精确匹配版本号同步到 tnpm 源 alifd CDN uipaas CDNtnpm run sync、tnpm run syncOss。此步骤把已发布在 npm 源的包同步到内部源对应脚本./scripts/sync.sh与node ./scripts/sync-oss.js因为 alifd CDN 依赖内部 npm 源更新发布日志Releases合并release/x.x.x到main分支合并main分支到develop分支。发 beta 版本beta 分三种情形命令差异在发布子命令上情形 A发某 y 位版本首个 beta如1.1.0-beta.0git checkout develop git pull # 更新到最新如需 git checkout -b release/1.1.0-beta git push --set-upstream origin release/1.1.0-beta npm run build npm run pub:preminor # 需有 alilc scope 发包权限 tnpm run sync tnpm run syncOss其中pub:preminor对应lerna publish preminor --force-publish --exact --dist-tag beta --preid beta --no-changelog即次版本号 1 并打betadist-tag、beta预发布前缀。情形 B发某 z 位版本首个 beta如1.0.1-beta.0流程与情形 A 相同区别仅在分支名release/1.0.1-beta与发布命令npm run pub:prepatch # lerna publish prepatch ... --dist-tag beta --preid beta情形 C发某版本非首个 beta如1.0.1-beta.0→1.0.1-beta.1git checkout release/1.0.1-beta git rebase origin/develop # 更新到 develop 分支最新代码 npm run build npm run pub:prerelease # 注意与首个 beta 时命令不同 tnpm run sync tnpm run syncOsspub:prerelease对应lerna publish prerelease --yes ... --dist-tag beta --preid beta——只递增预发布序列号-beta.N的 N适合在同一 release 分支上多轮发 beta。GitHub Actions 中的自动发布工作流仓库的.github/workflows目录为上述流程提供了自动化通道值得留意两个细节publish engine beta.yml当向匹配release/[0-9].[0-9].[0-9]-beta的分支 push 且变更涉及packages/**时自动触发执行npm install npm run setup→npm run build→npm run pub:prerelease使用NODE_AUTH_TOKEN完成 npm 认证最后输出新版本号。这正是“推送到 beta 分支即自动发下一轮 beta”的落地方式publish engine.yml手动触发workflow_dispatch需填写要执行的 publish 命令且限定在release/开头的分支、并白名单了两位发布负责人账号Node 版本为 16执行npm run $publishCommand。此外文档提示发布需要权限如果提 PR 后着急发布可以加入贡献者交流群与发布负责人沟通。六、DEMO 发布机制DEMO 与引擎本体的发布路径不同流程更轻量修改版本号手动修改 deploy-space/package.json 等 DEMO 侧 package.json 的版本号buildnpm run buildpublish需要 npm 发包权限npm run pub # 如发 beta 版 npm publish --tag beta同步tnpm run sync与tnpm run syncOss把包同步到 tnpm 源 alifd CDN uipaas CDN。最后一步“官网生效”需要在内部系统中更新 demo 版本后线上页面才会切换到新构建产物。七、要点速查事项命令 / 规则仓库证据提交前 linthusky pre-commit/commit-msgf2elintpackage.json、commitlint.config.js本地构建npm run buildpackage.json单包测试cd packages/pkg npm testtest packages.yml全量测试npm testlerna run test --streampackage.json覆盖率门禁核心模块 80%Codecov 上传ci.yml发正式版npm run publerna publish patchpackage.json、lerna.json发首个 betanpm run pub:preminor/pub:prepatchpackage.json发后续 betanpm run pub:prerelease可被 beta 分支 push 自动触发publish engine beta.yml环境要求仓库engines声明node 14.17.0 18贡献文档推荐 Node.js 16package.json、参与贡献需要注意的适用前提文档中的tnpm run sync/syncOss属于阿里内部源同步步骤外部贡献者通常只执行到npm run pub之前PR 的目标分支应为 developlowcode-engine 仓库从 develop 建分支、PR 指向 develop详见参与贡献。整体来看这套协作流程以 husky 本地钩子兜住风格与 commit 规范、以分包 CI job Codecov 兜住测试与覆盖率、以 lerna allowBranch 分支白名单 GitHub Actions 兜住发布安全构成了一个可追溯、可回退、可自动化的研发协作闭环。【免费下载链接】lowcode-engineAn enterprise-class low-code technology stack with scale-out design / 一套面向扩展设计的企业级低代码技术体系项目地址: https://gitcode.com/GitHub_Trending/lo/lowcode-engine创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
