- 前端
- 图形学
【免费下载链接】fabric.js
Javascript Canvas Library, SVG-to-Canvas (& canvas-to-SVG) Parser
本文基于 fabric.js 仓库的
.agents/skills/fabricjs-open-pr/SKILL.md技能文档，系统梳理向 fabricjs/fabric.js 提交 Pull Request 的完整规范：从输入收集、conventional-commit 风格标题、PR 描述编写，到强制性的 CHANGELOG 更新、PR 编号预测以及提交前的质量检查与冲突处理。读完本文，你将掌握一套可直接复用的开源 PR 操作流程，能够独立完成"写标题 → 写描述 → 预测编号 → 更新 changelog → 推送 → 创建 PR → 校正编号"的完整闭环。
一、技能定位与适用场景
fabricjs-open-pr技能面向所有需要向fabricjs/fabric.js提交代码的贡献者与自动化 Agent，核心解决三类问题：
- 首次提 PR：从分支、基分支、issue 引用收集输入，按规范生成标题与描述，同步维护 CHANGELOG；
- 已有 PR 维护：处理分支落后
master、merge 冲突（尤其是CHANGELOG.md专属冲突）、重新推送合并提交等场景； - 质量门禁：确保 lint、格式检查、pre-commit hooks 全部通过后才创建 PR。
技能规定了一条重要边界：一个 bug 一个 PR、一个 feature 一个 PR。如果变更涉及重构，也不要混入当前 PR，而是先让改动落地、观察稳定后，再单独发起重构类 PR。这一约定与仓库 CONTRIBUTING.md 中的"Don't create a PR from your fork main branch"、"Create a new branch for every pull request" 要求相互印证。
二、输入收集：从对话上下文推断而非反复提问
打开 PR 前需要收集或推断以下输入：
| 输入项 | 说明 |
|---|---|
| 分支（Branch to open） | 承载变更提交的分支名 |
| 基分支（Base branch） | 默认master，也可显式指定其他分支 |
| issue 编号（Issue number to close） | 可选，用于在 PR 描述中自动关闭对应 issue |
| 变更摘要（Short summary） | 用于生成标题与描述的一段简短说明 |
Issue 编号的处理规则（避免无意义地打断用户）：
- 如果当前对话线程中已经包含issue 编号，直接复用，不要再次询问；
- 如果用户明确说明没有issue，不要索要，也不要写任何关闭引用文本；
- 其余情况，才在创建 PR 描述前向用户确认 issue 编号。
这条规则的精髓是"能推断就不问"，与自动化 Agent 场景高度契合——减少往返、保持流程顺畅。
三、标题规则：严格遵循 conventional commits 风格
PR 标题必须是 short、meaningful 的 conventional-commit 风格：
<type>(<optional-scope>): <summary>- 允许的常见类型：
feat、fix、docs、ci、test、refactor、chore； - summary要简短且具体；
- type 与 scope 一律小写。
技能文档给出了三个可直接参考的示例：
ci(): fix coverage artifact download in comment workflow fix(coverage): flatten playwright istanbul output docs(changelog): align next entry format打开仓库根目录的 CHANGELOG.md 可以看到大量真实案例与之一一对应，例如fix(text): correct RTL cursor positioning in ...、refactor(core): move implementation source into package、ci(): fix for publishing action等。这些标题同时会出现在 GitHub 的 PR 列表与 changelog 中，因此标题的规范性直接决定了项目历史记录的整洁度。
四、PR 描述（Body）的强制结构
PR body 必须包含三部分，缺一不可：
- 一段简短的描述段落：说明"改了什么、为什么改"；
- 一个紧凑的关键变更列表：用 bullet list 列出核心变更点；
- 关闭引用：仅当提供了 issue 编号时，使用精确格式
close #<issue-num>；没有 issue 则完全不要写。
仓库的 .github/PULL_REQUEST_TEMPLATE.md 为这一结构提供了背书：模板内置## Description（要求概括变更原因、指出原代码错在哪里、你的方案为何更好；修复回归需链接引入 bug 的 commit；feature 需链接讨论的 issue）与## In Action（性能变更需附性能证明）两个章节，与技能要求的"描述段落 + 变更列表 + close 引用"相辅相成。
五、CHANGELOG 更新（强制步骤）
5.1 更新位置与格式
打开 PR 之前，必须确保CHANGELOG.md的## [next]部分新增了一行，格式为：
- <pr title> [#<predictedPrNum>](https://github.com/fabricjs/fabric.js/pull/<predictedPrNum>)规则约束：
- 使用与 PR 标题完全一致的文本；
- 插入到
[next]列表的靠前位置； - 保持原有格式不动，只加这一行。
5.2 仓库中的真实格式证据
打开 CHANGELOG.md 顶部即可看到## [next]的实际形态（当前为 fabric 7.4.0 之后的未发布版本区段），例如：
## [next] - chore(deps-dev): bump @playwright/test from 1.60.0 to 1.62.0 [#11063](https://github.com/fabricjs/fabric.js/pull/11063) - feat(): Add backend network request callback [#11064](https://github.com/fabricjs/fabric.js/pull/11064)从源码结构看，[next]是仓库面向下一个版本的滚动 changelog 区段，PR 合并前后所有新增条目都汇聚于此。技能要求"预测编号写入"的原因也在此：PR 编号在创建前是不可知的，但 changelog 行必须在创建 PR 前提交，因此只能先用预测编号占位。
5.3 自动化兜底：changelog 检查工作流
仓库还配置了 .github/workflows/changelog_check_and_create.yml，在pull_request事件（opened / synchronize / reopened / edited）触发时执行：
- 通过 GitHub API 获取 PR 变更文件列表；
- 若
CHANGELOG.md未被修改，或 PR 标题有变动，则生成- <title> [#<prNum>](https://github.com/fabricjs/fabric.js/pull/<prNum>)格式的 changelog 行作为 artifact，并让 CI 失败（exit 1）； - 若已正确修改，则校验通过（
exit 0）。
这说明 changelog 更新是仓库 CI 层面的硬性门禁，而非可选项；技能文档把它列为 Mandatory（强制），与工作流互相印证。CONTRIBUTING.md 同样要求："Add a concise listing to the CHANGELOG describing what has changed"。
六、预测下一个 PR 编号
在创建 PR 之前，需要从仓库根目录确定下一个 issue/PR 编号。首选命令（通常已足够）：
latest_num=$(gh api repos/fabricjs/fabric.js/issues?state=all\&per_page=1 --jq '.[0].number') predicted_pr_num=$((latest_num + 1))更完整的分页版本（必要时使用）：
latest_num=$(gh api repos/fabricjs/fabric.js/issues --paginate -F per_page=1 -F state=all --jq '.[0].number' | head -n1) predicted_pr_num=$((latest_num + 1))两种方式均基于 GitHub REST API：获取全仓库最新 issue/PR 的编号（issue 与 PR 在 GitHub 中共用编号序列），加 1 即为预测的下一个 PR 编号。随后用predicted_pr_num填充 changelog 行中的#<predictedPrNum>链接。
七、打开 PR 的完整工作流（14 步）
技能文档给出的标准操作序列如下：
确认分支已包含预期提交（intended commits）；
按 conventional-commit 风格构建 PR 标题；
解析 issue 引用：按上文 issue-number handling 规则从线程上下文判断；
有 issue 则在 body 写
close #<issue-num>，否则不写关闭文本；任何提交或创建 PR 之前，先跑质量检查：
npm run lint npm run prettier:check与最新
master同步：git fetch origin master git merge origin/master若产生 merge 冲突，先解决冲突再继续；
预测下一个 PR 编号（见上一节）；
用预测编号与标题更新
CHANGELOG.md的[next]行；提交并推送changelog/标题相关改动；严禁使用
--no-verify，pre-commit hooks 必须运行并通过；若 hooks 修改了文件或失败，staged 修复后重新提交，直到 hooks 全部通过；
创建 PR：
gh pr create --base <base> --head <branch> --title "<title>" --body-file <file>获取实际 PR 编号；
若实际编号与预测不符：更新 changelog 行为实际编号/链接 → 提交并推送修正 → 如有需要可在 PR body 补充简短说明。
7.1 质量检查与 hooks 的仓库实证
- package.json 中，
lint脚本为eslint extensions packages --fix（配合 eslint.config.mjs 使用），prettier:check为oxfmt --check .，另有prettier:write（oxfmt .）用于自动格式化；prepare脚本执行husky install； - .husky/pre-commit 中仅有一行
npx lint-staged，即通过 package.json 中的lint-staged依赖对暂存文件执行 lint/格式修复——这正是"hooks 可能修改文件、需要重新提交"的原因。
7.2 为什么禁止--no-verify
跳过 hooks 会让未通过 lint/格式检查的代码进入历史，破坏仓库统一的代码风格门禁。技能文档明确要求：hooks 修改了文件就 staged 修复并重新提交，直至通过——这是对 CONTRIBUTING.md 中"Fabric 使用 oxfmt 格式化、eslint 检查（pnpm run lint -- --fix）"规范的直接落地。
八、已有 PR 的维护与解除阻塞
当用户要求"finish"或"unblock"一个已存在的 Fabric.js PR 时，执行：
- 拉取最新
origin/master； - 若 PR 落后于基分支或被 merge 冲突阻塞，本地将
origin/master合并进 PR 分支； - 若冲突仅涉及
CHANGELOG.md，直接在合并过程中本地解决，不要询问用户是否处理； - 推送 merge commit到 PR 分支；
- 只有冲突涉及
CHANGELOG.md之外的文件、或解决方案存在歧义时，才停下来询问用户。
这条规则的合理性在于：changelog 冲突通常是"双方都往[next]列表头部插入"造成的机械性冲突，合并策略清晰（保留双方条目、重新按序排列），无需人工仲裁；而涉及业务代码的冲突则可能牵涉设计取舍，需要征求 PR 作者意见。
九、完成前的验证清单（Verification Checklist）
无论新建还是维护 PR，收尾前必须逐项核对：
- PR 标题遵循 conventional-commit 风格，且与 changelog 文本完全一致；
- PR body 包含描述段落；
- 若提供了 issue 编号，body 包含
close #<issue-num>； npm run lint通过；npm run prettier:check通过；- 本次 PR 相关提交未使用
--no-verify，pre-commit hooks 全部通过； - PR 创建前分支已与最新
master同步； - 维护已有 PR 时，若
CHANGELOG.md专属冲突足以解除阻塞，已合并origin/master到 PR 分支； CHANGELOG.md的[next]区段为本次 PR恰好新增一行（不多不少）；- 链接使用
https://github.com/fabricjs/fabric.js/pull/<prNum>格式（与仓库现有 changelog 条目格式一致）； - 若预测编号与实际不符，changelog 已修正并推送。
十、实操要点小结
- 标题先行：类型小写、摘要具体，
fix(coverage): flatten playwright istanbul output优于update tests； - changelog 行 = 标题 + 预测编号链接，插入
[next]顶部附近，格式严格仿照 CHANGELOG.md 现有条目； - 编号预测用
gh api：state=all&per_page=1取最新编号加 1，创建后立即用真实编号回写校正； - 任何提交前先跑
npm run lint与npm run prettier:check（对应 package.json 脚本），提交绝不跳过 hooks； - 冲突处理分级：仅
CHANGELOG.md冲突 → 自行本地合并；涉及其他文件 → 询问用户； - 一条 PR 只做一件事，分支从 fork 的独立分支创建，不使用主分支。
这套流程同时覆盖了仓库侧的 CONTRIBUTING.md 贡献规范、.github/PULL_REQUEST_TEMPLATE.md 描述模板、.github/workflows/changelog_check_and_create.yml CI 门禁与 .husky/pre-commit hooks，贡献者按本文操作即可一次性通过仓库全部质量关卡。
- 前端
- 图形学
【免费下载链接】fabric.js
Javascript Canvas Library, SVG-to-Canvas (& canvas-to-SVG) Parser
相关推荐
Conventional Changelog CLI工具完全指南
Conventional Changelog CLI工具完全指南 Conventional Changelog CLI 是一个功能强大的命令行工具，能够根据项目
开发工具CLI文档AionUi 贡献指南：原子化 PR、Conventional Commit 与本地质量检查全流程
AionUi 贡献指南：原子化 PR、Conventional Commit 与本地质量检查全流程 本篇指南以 AionUi 仓库根目录的 CONTRIBUTI
人工智能AI 应用AI Agent交互助手桌面应用移动开发AionUi 贡献指南：原子化 PR、Conventional Commit 与本地质量检查全流程
AionUi 贡献指南：原子化 PR、Conventional Commit 与本地质量检查全流程 本篇技术指南以 AionUi 开源仓库的 CONTRIBUT
人工智能AI 应用大模型AI Agent交互助手前端
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
