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-commit：f2elint commit-file-scan——对本次提交涉及的文件做 eslint/stylelint 扫描；commit-msg：f2elint 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 为每个核心包各配了一个独立 job：
test-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 test； - ci.yml 则负责覆盖率：对 designer、renderer-core、react-simulator-renderer、code-generator 四个模块执行
npm run test:cov，并把coverage/目录上传到 Codecov（fail_ci_if_error: true）。这正是“覆盖率下降不予通过”的自动执行载体——核心包的覆盖率数据持续可见、可对比。
三、commit 风格：Conventional Commits + 一个改动一个 commit
文档要求 commit message 遵循 Conventional Commits 规范（即type(scope): description结构），仓库中的落地配置有：
- commitlint.config.js：
extends: ['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 迭代，每年 2～4 次。
发正式版（以 1.0.0 为例）
- 切到 develop：
git checkout develop - 创建 release 分支：
git checkout -b release/1.0.0 - 构建：
npm run build - 发布到 npm：
npm run pub从 package.json 看，该脚本实际执行npm run watchdog:build && lerna publish patch --yes --force-publish --exact --no-changelog——先经 watchdog 守护构建，再强制全量发布、精确匹配版本号； - 同步到 tnpm 源 & alifd CDN & uipaas CDN：
tnpm 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.0）
git 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.1）
git 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 的版本号；
- build：
npm run build； - publish（需要 npm 发包权限）：
npm run pub # 如发 beta 版 npm publish --tag beta - 同步：
tnpm run sync与tnpm run syncOss，把包同步到 tnpm 源 & alifd CDN & uipaas CDN。
最后一步“官网生效”需要在内部系统中更新 demo 版本后，线上页面才会切换到新构建产物。
七、要点速查
| 事项 | 命令 / 规则 | 仓库证据 |
|---|---|---|
| 提交前 lint | husky pre-commit/commit-msg（f2elint） | package.json、commitlint.config.js |
| 本地构建 | npm run build | package.json |
| 单包测试 | cd packages/<pkg> && npm test | test packages.yml |
| 全量测试 | npm test（lerna run test --stream） | package.json |
| 覆盖率门禁 | 核心模块 80%+，Codecov 上传 | ci.yml |
| 发正式版 | npm run pub（lerna publish patch） | package.json、lerna.json |
| 发首个 beta | npm run pub:preminor/pub:prepatch | package.json |
| 发后续 beta | npm run pub:prerelease（可被 beta 分支 push 自动触发） | publish engine beta.yml |
| 环境要求 | 仓库engines声明node >=14.17.0 <18；贡献文档推荐 Node.js 16+ | package.json、参与贡献 |
需要注意的适用前提：文档中的tnpm run sync/syncOss属于阿里内部源同步步骤，外部贡献者通常只执行到npm run pub之前；PR 的目标分支应为 develop（lowcode-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），仅供参考
