p5.js 维护者手册Issue 与 Pull Request 审查、构建与发布全流程指南【免费下载链接】p5.jsp5.js is a client-side JS platform that empowers artists, designers, students, and anyone to learn to code and express themselves creatively on the web. It is based on the core principles of Processing. Looking for p5.js 2.0? http://beta.p5js.org项目地址: https://gitcode.com/GitHub_Trending/p5/p5.js本篇技术指南以 p5.js 仓库的 管理员指南 为核心系统讲解 p5.js 开源项目的维护者Steward/管理员如何审查 Issue、评审并合并 Pull Request、理解构建与测试流水线、执行版本发布并借助回复模板、GitHub CLI 与通知设置提升审查效率。读完本文你将掌握一套可直接复用的 p5.js 贡献治理工作流并能对照当前仓库的源码、配置与 CI 工作流验证每一个环节的实际落地方式。角色定位与指南性质p5.js 仓库中存在两类维护角色steward管理员与maintainer维护者。steward 通常负责特定功能领域如 WebGL、Typography、i18n、Accessibility而 maintainer 拥有更广泛的合并与发布权限。仓库根目录的 stewards.yml 明确记录了各领域负责人的 GitHub 账号与其负责的子领域例如 Accessibility、Core、Graphics含 WebGL/WebGPU、Typography、p5.sound.js、DevOps、Documentation、Color、i18nzh/hi/es/ko、p5.js-website 等。需要强调的是该指南中的绝大多数内容是指导性建议而非强制规则维护者可以根据自己的工作流灵活调整。但有两个底层共识贯穿全文几乎所有代码贡献都应先有 Issue、后有 Pull Request且所有合入代码都必须通过自动化 CI 测试。Issues 管理p5.js 鼓励大部分源代码贡献以 Issue 为起点。仓库通过 Issue 模板 将不同类型的 Issue 组织起来审查的第一步通常是核对模板填写是否完整、是否选用了正确的模板。当前仓库共提供五套模板1-p5.js-2.0-bug-report.yml针对 p5.js 2.0 的 Bug 报告2-found-a-bug.yml常规 Bug 报告3-existing-feature-enhancement.yml现有功能增强4-feature-request.yml新功能请求5-discussion.yml开放式讨论。Bug 报告Bug 报告使用发现了一个 bug模板处理流程如下复现 Bug。模板的设计目标就是提供足够的复现信息。若报告的 Bug 与 p5.js 或 p5.js-website 仓库无关有权限的审查者应将该 Issue 转移到对应仓库否则应留下评论说明应提交到哪里然后关闭 Issue。如果可以复现必要时参考 p5.js 的设计原则文档当前仓库中已归档讨论修复方案。若作者愿意提供修复批准并为其分配 Issue若作者不愿修复则确认 Bug 可复现并添加需要帮助标签。如果无法复现要求补充环境信息p5.js 版本、浏览器版本、操作系统版本等若测试环境不同应说明无法复现并添加需要帮助标签请具备相同环境的贡献者尝试复现若 Bug 只在 [web 编辑器]中复现则转入 web 编辑器仓库处理。如果 Bug 源于用户代码而非 p5.js 行为判断能否通过改进文档、代码实现或友好错误系统FES来预防同类错误并将进一步问题友好地引导至论坛或 Discord。以真实模板为参照2-found-a-bug.yml 要求填写 p5.js 版本、浏览器及版本、操作系统及版本、复现步骤与代码片段并列出 Accessibility、Color、Core/Environment/Rendering、Data、DOM、Events、Image、IO、Math、Typography、Utilities、WebGL、WebGPU、p5.strands、Build process、Unit testing、Internationalization、Friendly errors 等子领域复选框审查者可以据此快速判断该 Bug 属于哪个 stewards 的管辖范围。功能请求功能请求使用新功能请求模板其审查流程最具 p5.js 特色可访问性门槛作为 p5.js 无障碍工作的一部分所有功能请求必须说明它如何提高对历史上被边缘化群体社区的可访问性详见访问说明。若该字段填写不充分可要求作者补充也可由社区其他成员代为提供。范围与兼容性评估是否符合项目范围与设计原则例如新增一个绘图原始形状的请求是合理的而基于浏览器的物联网协议请求则超出范围。p5.js 刻意保持较窄的功能范围避免代码库臃肿超出范围的功能可建议作者做成附加库addon library甚至先以附加库形式做概念验证。是否属于破坏性变更是否会与现有函数/变量冲突是否会与典型示例冲突若可能冲突在未进行重大版本发布前不应合入。能否用已有 p5.js 功能、原生 JavaScript 或现有库实现例如连接字符串数组不必新增join函数直接使用原生[Hello, world!].join()即可。双人审批在满足可访问性要求与其他考虑后新功能请求在开始 PR 前必须获得至少两名 steward 或 maintainer 的批准。4-feature-request.yml 将Increasing access提高可访问性设置为必填字段不确定时可填写 Unsure 交由社区补充并固定打上Feature Request标签从模板层面强制落实上述门槛。功能增强功能增强使用现有功能增强模板流程与新功能请求类似但边界更严格与新增功能相同只有能提高 p5.js 可访问性时才应被接受。特别注意破坏性变更修改现有功能时所有先前有效且记录在案的功能签名必须以相同方式运行。在开始 PR 前至少由一名 steward 或 maintainer批准即可低于新功能请求的双人门槛。讨论讨论类 Issue 使用极简模板用于在主题收敛为具体内容如功能请求之前收集一般性反馈。审查时的处理原则若讨论实为 Bug 报告应改用正确标签、移除讨论标签并向作者索取缺失信息若讨论与源代码贡献或仓库流程无关如讨论草图用哪种投影仪应重定向到论坛或 Discord 并关闭适用时添加其他标签进一步标识讨论类型。拉取请求审查几乎所有代码贡献都通过 Pull Request 进行。即便是拥有推送权限的 steward 与 maintainer也鼓励遵循相同的 Issue → PR → 审查流程。PULL_REQUEST_TEMPLATE.md 要求 PR 描述中包含Resolves #XXXX完全解决或addresses #XXXX部分解决合并不自动关闭 Issue并附三项目检清单npm run lint通过、内联参考文档已包含/更新、单元测试已包含/更新。审查前的通用规则除极小的拼写错误修正外几乎所有 PR 都必须先有对应的 Issue拼写修正例外可由任何具有合并权限的人直接合并若 PR 未完全解决引用 Issue可将原帖中的解决 #OOOO改为处理 #OOOO避免合并时自动关闭 Issue。简单修复类似拼写错误修正的简单修复任何具有合并访问权限的人都可以直接合并只需快速检查 PR 的更改的文件Files changed选项卡并确认自动化 CI 通过即可。Bug 修复由相关领域的 steward 审查最好是当初同意修复该 Issue 的同一人先用更改的文件选项卡初步核对修复是否与 Issue 讨论一致尽可能在本地测试GitHub CLI 可大幅简化此过程验收标准包括修复足以解决原始 Issue不改变既有行为除非 Issue 中已达成一致不显著影响性能不影响可访问性使用现代标准 JavaScript 编写通过全部自动化测试并尽量包含新测试需要修改时使用行级评论可借助建议修改Suggest Change 功能给出具体代码建议多处修改应使用多行评论并请求更改Request changes若行级评论仅用于澄清讨论则选择 Comment 而非 Request changes审查通过后选择 Approve 将 PR 标记为已批准随后由具备权限者合并通过调用 all-contributors 机器人将新贡献者加入 README 的贡献者列表命令格式为all-contributors please add [GitHub handle] for [contribution type]新功能 / 功能增强流程与 Bug 修复一致唯一显著区别是合并前必须由至少两名 steward 或 maintainer 审查并批准与前面 Issue 阶段的双人批准门槛相呼应。DependabotDependabot 的 PR 通常仅对仓库管理员可见。处理策略按语义化版本分级补丁版本patchCI 通过即可直接合并次要版本minorCI 通过通常可直接合并但建议快速查看更新依赖的变更日志主版本major可能影响构建或功能应尽量从当前版本到目标版本核对变更日志并在本地测试。注意许多依赖提升主版本仅仅是因为不再支持过旧的 Node.js 版本并不一定意味着破坏性 API 变更。构建过程原指南以 Gruntfile.js 为线索描述了 p5.js 的经典构建体系使用 Grunt、Browserify、YUIDoc、ESLint、Babel、Uglify、Mocha 等工具。需要特别说明的是当前仓库package.json 中版本为 2.3.1已将构建体系迁移为 rolldown vite vitest oxlintrolldown.config.js 取代了 Gruntfile.jspackage.json 中的脚本相应变为build: rolldown -c、test: vitest、lint: oxlint .。下面先忠实还原指南描述的经典流水线便于理解设计意图再给出当前仓库的实际对应物。经典构建任务指南所述default任务由lint与test组成grunt.registerTask(default, [lint, test]);运行grunt或npm test即执行该默认任务。lint任务grunt.registerTask(lint, [lint:source, lint:samples]);lint:source拆分为eslint:build、eslint:source、eslint:test三个子任务分别用 ESLint 检查构建脚本、源代码与测试脚本lint:samples先运行yui任务yuidoc:prod→clean:reference→minjson从源码提取文档为 JSON 并压缩成data.min.json随后运行自定义任务eslint-samples:source用 ESLint 检查文档中的示例代码确保其遵循与源码相同的编码规范。test任务grunt.registerTask(test, [ build, connect:server, mochaChrome, mochaTest, nyc:report ]);其中build又展开为grunt.registerTask(build, [ browserify, browserify:min, uglify, browserify:test ]);各环节的职责browserify构建完整 p5.jsbrowserify:min构建后续压缩用的中间文件区别在于不包含友好错误系统FES运行所需的数据uglify将browserify:min的输出压缩为最终的p5.min.jsbrowserify:test构建与完整版相同但额外加入基于 Istanbul 的覆盖率统计代码打包过程中brfs-babel将fs.readFileSync()这类 Node.js 特有代码替换为文件实际内容主要用于把独立编写的 WebGL 着色器内联进源码Babel 将 node_modules 依赖按 Browserslist 要求转译并把 ES6 导入转换为 Browserify 可识别的 CommonJSrequire()捆绑后代码还会经过pretty-fast格式化以保持可读性。测试链路的其余步骤connect:server启动本地服务器托管测试文件与构建产物供 Chrome 运行自动化测试mochaChrome基于 Puppeteer 启动可远程控制的无头 Chrome运行与test目录下 HTML 文件关联的测试——包括对未压缩与压缩版本的单元测试以及所有参考示例的测试mochaTest在 Node.js 环境运行仅覆盖一小部分无需浏览器环境的功能因此除非新测试确实不依赖浏览器否则不应扩展该集合nyc:report汇总覆盖率并打印到控制台。p5.js 的覆盖率主要用于监控与提供数据点目标并非 100% 覆盖率。当前仓库的构建体系v2.3.1 现状从源码结构看经典流水线的职责在现行体系中依然清晰可辨只是换成了更现代的打包工具rolldown.config.js 定义了多份产物lib/p5.jsIIFE 格式、带版本横幅、lib/p5.esm.jsESM 格式、lib/p5.min.jsminify 构建并通过 alias 将./core/friendly_errors替换为./core/noop——这与经典构建中min 版本不包含 FES 数据的意图一脉相承此外还以src/webgpu/index.js为入口产出lib/p5.webgpu.js、lib/p5.webgpu.min.js、lib/p5.webgpu.esm.js并通过 glob 将src/**/*.js逐文件输出到dist/供 ESM 按模块引入着色器内联依然存在rollup-plugin-string插件将src/webgl/shaders/**/*的内容作为字符串打入产物与当年brfs-babel内联 WebGL 着色器的做法相对应vitest.config.js 定义了unit-tests与unit-tests-webgpu两个测试项目均通过 Playwright 驱动 Chromium 运行后者在 CI 环境下额外传入--enable-unsafe-webgpu、--use-vulkanswiftshader等参数以支持无头 WebGPU 测试.github/workflows/ci-test.yml 展示了真实 CI 链路Node.js 22.x →npm ci→npm test -- --projectunit-tests→node visual-report.js生成可视化测试报告 →npm run generate-types生成 TypeScript 类型 →npm run test:types校验类型ci-lint.yml 对应 lint 环节。仓库还包含labeler.yml、stewards-update.yml、auto-close-issues.yml、contributors-png.yml等工作流分别负责自动打标签、更新 stewards.yml 领域表、自动关闭无回应 Issue 等。杂项任务经典 Grunt 时代还提供以下辅助任务现代仓库中对应概念可参考 vite 的 watch 能力与 package.json 的dev/dev:global脚本grunt yui:dev构建文档与库后启动一个与官网参考页功能类似的站点localhost:9001/docs/reference/并监视源码变化自动重新构建。适合修改内联文档时直接预览无需将构建产物搬到 p5.js-website 仓库但参考页本身的样式与布局改动仍应在网站仓库中进行grunt watch检测到任何源码变更即运行全部构建与测试相当于完整默认任务grunt watch:main仅运行库构建与测试不重建参考文档grunt watch:quick仅运行库构建。选择最简化的 watch 任务可显著节省手动重建时间。所有步骤、子步骤均可用npx grunt [step]单独执行。发布过程发布流程的完整细节见发布流程文档指南在此仅作指向。核心要点如下遵循语义化版本主版本号.次版本号.修订号发布前置要求本机安装 Git、Node.js 与 npm具备远程仓库推送权限仓库已配置NPM_TOKEN与ACCESS_TOKEN两个密钥发布操作极其简洁实际步骤全部由 GitHub Actions CI 完成git checkout main npm version [major|minor|patch] # 选择适当的版本标签 git push origin main git push origin v1.4.2 # 替换为刚创建的版本号CI 在匹配v*.*.*格式的标签上触发依次执行克隆仓库、安装依赖、npm test跑测试构建发布文件在 GitHub 创建 Release 并发布到 npm更新 p5.js-website 仓库复制data.json、data.min.json、p5.min.js、p5.sound.min.js更新data.yml与en.json更新 Bower 发布仓库的库文件原则是尽可能把发布步骤集中在 CI 中定义新增的发布步骤也应写入 CI 工作流而非构建配置本地可用act工具模拟测试发布工作流但需要临时修改工作流定义并安装系统依赖。在当前仓库中可对照 .github/workflows 下的release-workflow-v1.yml、release-workflow-v2.yml与continuous-release.yml查看发布与持续发布的实际定义。提示与技巧当待审查的 Issue 与 PR 数量庞大时以下技巧能显著提升效率。回复模板GitHub 的 Saved Replies已保存回复功能适用于上述流程中大量重复出现的回复场景。以下是 p5.js 维护者实际使用的一些模板可直接复用或改造成自己的版本关闭无法重现我们无法重现这个 issue但如果你能提供一个演示问题的代码示例请随时重新打开这个 issue。谢谢关闭需要代码片段为了组织的目的我们关闭了此 issue。如果您能提供一个说明问题的代码片段请重新打开该 issue。谢谢关闭使用论坛这里的 GitHub issues 是报告 p5.js 库本身的错误和问题的好地方。如果你有关于编写自己的代码、测试或遵循教程的问题请在论坛上发布。谢谢关闭GSOC谢谢讨论 GSOC 提案的最佳地方是我们的论坛。关闭访问权限目前看来这个功能并没有引起太多关注而且我们还没有一个清晰的解释来说明它是如何扩大访问权限的因此我们现在将关闭这个 issue。如果能够在 issue 请求中添加一个关于访问权限的声明请随时重新打开此 issue。我们暂时关闭了此 issue因为没有看到对此 issue 的较详细解释访问权限。如果可以在 issue 请求中添加更详细的访问权限说明请随时重新打开。谢谢关闭插件我们认为这个功能超出了 p5.js API 的范围我们尽量保持最简化但它可以成为一个很好的插件库的起点。请查看此处的文档了解如何创建一个插件 创建库文档关闭 PR先提出 issue谢谢。作为提醒必须在打开拉取请求之前打开 issues 并使用 issues 标记拉取请求。这对于跟踪开发并保持讨论清晰是必要的。谢谢批准 issue 修复你可以继续进行修复。谢谢。合并 PR看起来不错。谢谢GitHub CLI复杂的 PR 审查常因繁琐的 git 命令获取 fork、切分支、本地测试而变得困难GitHub CLI 可以极大简化该过程。安装并登录后只需一条命令即可在本地审查任意 PRgh pr checkout [pull_request_id]该命令会自动获取远程 fork、创建分支并切换过去返回主分支只需git checkout main。此外还可直接从 CLI 在 PR 中留言而无需访问网页。管理通知无需再手动刷新仓库的 Issues / Pull Requests 选项卡——通过仓库页面顶部的 Watch 按钮关注该仓库即可关注后新 Issue、新 PR、提及你的用户名等订阅活动都会进入通知页面可像处理邮件收件箱一样标记已读或忽略也可在通知设置页面自定义电子邮件通知频率甚至完全退订。起始建议是关注该仓库的 Issues 与 Pull Requests并将电子邮件通知设置为仅在参与、提及和自定义时接收——既避免手动翻找又不被海量通知淹没。结语从 Issue 的分类审查、PR 的分级审批到构建测试流水线与自动化发布p5.js 的维护体系始终围绕两个原则运转让每项变更都有迹可循Issue 驱动、让每次合入都有质量保障双人审查 CI。对照本文给出的仓库文件——Issue 模板、PR 模板、rolldown.config.js、vitest.config.js、CI 工作流、stewards.yml 与发布流程文档——你可以逐项验证并复用这套流程无论是作为新 steward 快速上手还是作为贡献者理解 PR 被如何评审都能从中找到明确答案。若想进一步了解本地开发与构建命令的实操细节可继续阅读贡献者指南。【免费下载链接】p5.jsp5.js is a client-side JS platform that empowers artists, designers, students, and anyone to learn to code and express themselves creatively on the web. It is based on the core principles of Processing. Looking for p5.js 2.0? http://beta.p5js.org项目地址: https://gitcode.com/GitHub_Trending/p5/p5.js创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
p5.js 维护者手册：Issue 与 Pull Request 审查、构建与发布全流程指南
p5.js 维护者手册Issue 与 Pull Request 审查、构建与发布全流程指南【免费下载链接】p5.jsp5.js is a client-side JS platform that empowers artists, designers, students, and anyone to learn to code and express themselves creatively on the web. It is based on the core principles of Processing. Looking for p5.js 2.0? http://beta.p5js.org项目地址: https://gitcode.com/GitHub_Trending/p5/p5.js本篇技术指南以 p5.js 仓库的 管理员指南 为核心系统讲解 p5.js 开源项目的维护者Steward/管理员如何审查 Issue、评审并合并 Pull Request、理解构建与测试流水线、执行版本发布并借助回复模板、GitHub CLI 与通知设置提升审查效率。读完本文你将掌握一套可直接复用的 p5.js 贡献治理工作流并能对照当前仓库的源码、配置与 CI 工作流验证每一个环节的实际落地方式。角色定位与指南性质p5.js 仓库中存在两类维护角色steward管理员与maintainer维护者。steward 通常负责特定功能领域如 WebGL、Typography、i18n、Accessibility而 maintainer 拥有更广泛的合并与发布权限。仓库根目录的 stewards.yml 明确记录了各领域负责人的 GitHub 账号与其负责的子领域例如 Accessibility、Core、Graphics含 WebGL/WebGPU、Typography、p5.sound.js、DevOps、Documentation、Color、i18nzh/hi/es/ko、p5.js-website 等。需要强调的是该指南中的绝大多数内容是指导性建议而非强制规则维护者可以根据自己的工作流灵活调整。但有两个底层共识贯穿全文几乎所有代码贡献都应先有 Issue、后有 Pull Request且所有合入代码都必须通过自动化 CI 测试。Issues 管理p5.js 鼓励大部分源代码贡献以 Issue 为起点。仓库通过 Issue 模板 将不同类型的 Issue 组织起来审查的第一步通常是核对模板填写是否完整、是否选用了正确的模板。当前仓库共提供五套模板1-p5.js-2.0-bug-report.yml针对 p5.js 2.0 的 Bug 报告2-found-a-bug.yml常规 Bug 报告3-existing-feature-enhancement.yml现有功能增强4-feature-request.yml新功能请求5-discussion.yml开放式讨论。Bug 报告Bug 报告使用发现了一个 bug模板处理流程如下复现 Bug。模板的设计目标就是提供足够的复现信息。若报告的 Bug 与 p5.js 或 p5.js-website 仓库无关有权限的审查者应将该 Issue 转移到对应仓库否则应留下评论说明应提交到哪里然后关闭 Issue。如果可以复现必要时参考 p5.js 的设计原则文档当前仓库中已归档讨论修复方案。若作者愿意提供修复批准并为其分配 Issue若作者不愿修复则确认 Bug 可复现并添加需要帮助标签。如果无法复现要求补充环境信息p5.js 版本、浏览器版本、操作系统版本等若测试环境不同应说明无法复现并添加需要帮助标签请具备相同环境的贡献者尝试复现若 Bug 只在 [web 编辑器]中复现则转入 web 编辑器仓库处理。如果 Bug 源于用户代码而非 p5.js 行为判断能否通过改进文档、代码实现或友好错误系统FES来预防同类错误并将进一步问题友好地引导至论坛或 Discord。以真实模板为参照2-found-a-bug.yml 要求填写 p5.js 版本、浏览器及版本、操作系统及版本、复现步骤与代码片段并列出 Accessibility、Color、Core/Environment/Rendering、Data、DOM、Events、Image、IO、Math、Typography、Utilities、WebGL、WebGPU、p5.strands、Build process、Unit testing、Internationalization、Friendly errors 等子领域复选框审查者可以据此快速判断该 Bug 属于哪个 stewards 的管辖范围。功能请求功能请求使用新功能请求模板其审查流程最具 p5.js 特色可访问性门槛作为 p5.js 无障碍工作的一部分所有功能请求必须说明它如何提高对历史上被边缘化群体社区的可访问性详见访问说明。若该字段填写不充分可要求作者补充也可由社区其他成员代为提供。范围与兼容性评估是否符合项目范围与设计原则例如新增一个绘图原始形状的请求是合理的而基于浏览器的物联网协议请求则超出范围。p5.js 刻意保持较窄的功能范围避免代码库臃肿超出范围的功能可建议作者做成附加库addon library甚至先以附加库形式做概念验证。是否属于破坏性变更是否会与现有函数/变量冲突是否会与典型示例冲突若可能冲突在未进行重大版本发布前不应合入。能否用已有 p5.js 功能、原生 JavaScript 或现有库实现例如连接字符串数组不必新增join函数直接使用原生[Hello, world!].join()即可。双人审批在满足可访问性要求与其他考虑后新功能请求在开始 PR 前必须获得至少两名 steward 或 maintainer 的批准。4-feature-request.yml 将Increasing access提高可访问性设置为必填字段不确定时可填写 Unsure 交由社区补充并固定打上Feature Request标签从模板层面强制落实上述门槛。功能增强功能增强使用现有功能增强模板流程与新功能请求类似但边界更严格与新增功能相同只有能提高 p5.js 可访问性时才应被接受。特别注意破坏性变更修改现有功能时所有先前有效且记录在案的功能签名必须以相同方式运行。在开始 PR 前至少由一名 steward 或 maintainer批准即可低于新功能请求的双人门槛。讨论讨论类 Issue 使用极简模板用于在主题收敛为具体内容如功能请求之前收集一般性反馈。审查时的处理原则若讨论实为 Bug 报告应改用正确标签、移除讨论标签并向作者索取缺失信息若讨论与源代码贡献或仓库流程无关如讨论草图用哪种投影仪应重定向到论坛或 Discord 并关闭适用时添加其他标签进一步标识讨论类型。拉取请求审查几乎所有代码贡献都通过 Pull Request 进行。即便是拥有推送权限的 steward 与 maintainer也鼓励遵循相同的 Issue → PR → 审查流程。PULL_REQUEST_TEMPLATE.md 要求 PR 描述中包含Resolves #XXXX完全解决或addresses #XXXX部分解决合并不自动关闭 Issue并附三项目检清单npm run lint通过、内联参考文档已包含/更新、单元测试已包含/更新。审查前的通用规则除极小的拼写错误修正外几乎所有 PR 都必须先有对应的 Issue拼写修正例外可由任何具有合并权限的人直接合并若 PR 未完全解决引用 Issue可将原帖中的解决 #OOOO改为处理 #OOOO避免合并时自动关闭 Issue。简单修复类似拼写错误修正的简单修复任何具有合并访问权限的人都可以直接合并只需快速检查 PR 的更改的文件Files changed选项卡并确认自动化 CI 通过即可。Bug 修复由相关领域的 steward 审查最好是当初同意修复该 Issue 的同一人先用更改的文件选项卡初步核对修复是否与 Issue 讨论一致尽可能在本地测试GitHub CLI 可大幅简化此过程验收标准包括修复足以解决原始 Issue不改变既有行为除非 Issue 中已达成一致不显著影响性能不影响可访问性使用现代标准 JavaScript 编写通过全部自动化测试并尽量包含新测试需要修改时使用行级评论可借助建议修改Suggest Change 功能给出具体代码建议多处修改应使用多行评论并请求更改Request changes若行级评论仅用于澄清讨论则选择 Comment 而非 Request changes审查通过后选择 Approve 将 PR 标记为已批准随后由具备权限者合并通过调用 all-contributors 机器人将新贡献者加入 README 的贡献者列表命令格式为all-contributors please add [GitHub handle] for [contribution type]新功能 / 功能增强流程与 Bug 修复一致唯一显著区别是合并前必须由至少两名 steward 或 maintainer 审查并批准与前面 Issue 阶段的双人批准门槛相呼应。DependabotDependabot 的 PR 通常仅对仓库管理员可见。处理策略按语义化版本分级补丁版本patchCI 通过即可直接合并次要版本minorCI 通过通常可直接合并但建议快速查看更新依赖的变更日志主版本major可能影响构建或功能应尽量从当前版本到目标版本核对变更日志并在本地测试。注意许多依赖提升主版本仅仅是因为不再支持过旧的 Node.js 版本并不一定意味着破坏性 API 变更。构建过程原指南以 Gruntfile.js 为线索描述了 p5.js 的经典构建体系使用 Grunt、Browserify、YUIDoc、ESLint、Babel、Uglify、Mocha 等工具。需要特别说明的是当前仓库package.json 中版本为 2.3.1已将构建体系迁移为 rolldown vite vitest oxlintrolldown.config.js 取代了 Gruntfile.jspackage.json 中的脚本相应变为build: rolldown -c、test: vitest、lint: oxlint .。下面先忠实还原指南描述的经典流水线便于理解设计意图再给出当前仓库的实际对应物。经典构建任务指南所述default任务由lint与test组成grunt.registerTask(default, [lint, test]);运行grunt或npm test即执行该默认任务。lint任务grunt.registerTask(lint, [lint:source, lint:samples]);lint:source拆分为eslint:build、eslint:source、eslint:test三个子任务分别用 ESLint 检查构建脚本、源代码与测试脚本lint:samples先运行yui任务yuidoc:prod→clean:reference→minjson从源码提取文档为 JSON 并压缩成data.min.json随后运行自定义任务eslint-samples:source用 ESLint 检查文档中的示例代码确保其遵循与源码相同的编码规范。test任务grunt.registerTask(test, [ build, connect:server, mochaChrome, mochaTest, nyc:report ]);其中build又展开为grunt.registerTask(build, [ browserify, browserify:min, uglify, browserify:test ]);各环节的职责browserify构建完整 p5.jsbrowserify:min构建后续压缩用的中间文件区别在于不包含友好错误系统FES运行所需的数据uglify将browserify:min的输出压缩为最终的p5.min.jsbrowserify:test构建与完整版相同但额外加入基于 Istanbul 的覆盖率统计代码打包过程中brfs-babel将fs.readFileSync()这类 Node.js 特有代码替换为文件实际内容主要用于把独立编写的 WebGL 着色器内联进源码Babel 将 node_modules 依赖按 Browserslist 要求转译并把 ES6 导入转换为 Browserify 可识别的 CommonJSrequire()捆绑后代码还会经过pretty-fast格式化以保持可读性。测试链路的其余步骤connect:server启动本地服务器托管测试文件与构建产物供 Chrome 运行自动化测试mochaChrome基于 Puppeteer 启动可远程控制的无头 Chrome运行与test目录下 HTML 文件关联的测试——包括对未压缩与压缩版本的单元测试以及所有参考示例的测试mochaTest在 Node.js 环境运行仅覆盖一小部分无需浏览器环境的功能因此除非新测试确实不依赖浏览器否则不应扩展该集合nyc:report汇总覆盖率并打印到控制台。p5.js 的覆盖率主要用于监控与提供数据点目标并非 100% 覆盖率。当前仓库的构建体系v2.3.1 现状从源码结构看经典流水线的职责在现行体系中依然清晰可辨只是换成了更现代的打包工具rolldown.config.js 定义了多份产物lib/p5.jsIIFE 格式、带版本横幅、lib/p5.esm.jsESM 格式、lib/p5.min.jsminify 构建并通过 alias 将./core/friendly_errors替换为./core/noop——这与经典构建中min 版本不包含 FES 数据的意图一脉相承此外还以src/webgpu/index.js为入口产出lib/p5.webgpu.js、lib/p5.webgpu.min.js、lib/p5.webgpu.esm.js并通过 glob 将src/**/*.js逐文件输出到dist/供 ESM 按模块引入着色器内联依然存在rollup-plugin-string插件将src/webgl/shaders/**/*的内容作为字符串打入产物与当年brfs-babel内联 WebGL 着色器的做法相对应vitest.config.js 定义了unit-tests与unit-tests-webgpu两个测试项目均通过 Playwright 驱动 Chromium 运行后者在 CI 环境下额外传入--enable-unsafe-webgpu、--use-vulkanswiftshader等参数以支持无头 WebGPU 测试.github/workflows/ci-test.yml 展示了真实 CI 链路Node.js 22.x →npm ci→npm test -- --projectunit-tests→node visual-report.js生成可视化测试报告 →npm run generate-types生成 TypeScript 类型 →npm run test:types校验类型ci-lint.yml 对应 lint 环节。仓库还包含labeler.yml、stewards-update.yml、auto-close-issues.yml、contributors-png.yml等工作流分别负责自动打标签、更新 stewards.yml 领域表、自动关闭无回应 Issue 等。杂项任务经典 Grunt 时代还提供以下辅助任务现代仓库中对应概念可参考 vite 的 watch 能力与 package.json 的dev/dev:global脚本grunt yui:dev构建文档与库后启动一个与官网参考页功能类似的站点localhost:9001/docs/reference/并监视源码变化自动重新构建。适合修改内联文档时直接预览无需将构建产物搬到 p5.js-website 仓库但参考页本身的样式与布局改动仍应在网站仓库中进行grunt watch检测到任何源码变更即运行全部构建与测试相当于完整默认任务grunt watch:main仅运行库构建与测试不重建参考文档grunt watch:quick仅运行库构建。选择最简化的 watch 任务可显著节省手动重建时间。所有步骤、子步骤均可用npx grunt [step]单独执行。发布过程发布流程的完整细节见发布流程文档指南在此仅作指向。核心要点如下遵循语义化版本主版本号.次版本号.修订号发布前置要求本机安装 Git、Node.js 与 npm具备远程仓库推送权限仓库已配置NPM_TOKEN与ACCESS_TOKEN两个密钥发布操作极其简洁实际步骤全部由 GitHub Actions CI 完成git checkout main npm version [major|minor|patch] # 选择适当的版本标签 git push origin main git push origin v1.4.2 # 替换为刚创建的版本号CI 在匹配v*.*.*格式的标签上触发依次执行克隆仓库、安装依赖、npm test跑测试构建发布文件在 GitHub 创建 Release 并发布到 npm更新 p5.js-website 仓库复制data.json、data.min.json、p5.min.js、p5.sound.min.js更新data.yml与en.json更新 Bower 发布仓库的库文件原则是尽可能把发布步骤集中在 CI 中定义新增的发布步骤也应写入 CI 工作流而非构建配置本地可用act工具模拟测试发布工作流但需要临时修改工作流定义并安装系统依赖。在当前仓库中可对照 .github/workflows 下的release-workflow-v1.yml、release-workflow-v2.yml与continuous-release.yml查看发布与持续发布的实际定义。提示与技巧当待审查的 Issue 与 PR 数量庞大时以下技巧能显著提升效率。回复模板GitHub 的 Saved Replies已保存回复功能适用于上述流程中大量重复出现的回复场景。以下是 p5.js 维护者实际使用的一些模板可直接复用或改造成自己的版本关闭无法重现我们无法重现这个 issue但如果你能提供一个演示问题的代码示例请随时重新打开这个 issue。谢谢关闭需要代码片段为了组织的目的我们关闭了此 issue。如果您能提供一个说明问题的代码片段请重新打开该 issue。谢谢关闭使用论坛这里的 GitHub issues 是报告 p5.js 库本身的错误和问题的好地方。如果你有关于编写自己的代码、测试或遵循教程的问题请在论坛上发布。谢谢关闭GSOC谢谢讨论 GSOC 提案的最佳地方是我们的论坛。关闭访问权限目前看来这个功能并没有引起太多关注而且我们还没有一个清晰的解释来说明它是如何扩大访问权限的因此我们现在将关闭这个 issue。如果能够在 issue 请求中添加一个关于访问权限的声明请随时重新打开此 issue。我们暂时关闭了此 issue因为没有看到对此 issue 的较详细解释访问权限。如果可以在 issue 请求中添加更详细的访问权限说明请随时重新打开。谢谢关闭插件我们认为这个功能超出了 p5.js API 的范围我们尽量保持最简化但它可以成为一个很好的插件库的起点。请查看此处的文档了解如何创建一个插件 创建库文档关闭 PR先提出 issue谢谢。作为提醒必须在打开拉取请求之前打开 issues 并使用 issues 标记拉取请求。这对于跟踪开发并保持讨论清晰是必要的。谢谢批准 issue 修复你可以继续进行修复。谢谢。合并 PR看起来不错。谢谢GitHub CLI复杂的 PR 审查常因繁琐的 git 命令获取 fork、切分支、本地测试而变得困难GitHub CLI 可以极大简化该过程。安装并登录后只需一条命令即可在本地审查任意 PRgh pr checkout [pull_request_id]该命令会自动获取远程 fork、创建分支并切换过去返回主分支只需git checkout main。此外还可直接从 CLI 在 PR 中留言而无需访问网页。管理通知无需再手动刷新仓库的 Issues / Pull Requests 选项卡——通过仓库页面顶部的 Watch 按钮关注该仓库即可关注后新 Issue、新 PR、提及你的用户名等订阅活动都会进入通知页面可像处理邮件收件箱一样标记已读或忽略也可在通知设置页面自定义电子邮件通知频率甚至完全退订。起始建议是关注该仓库的 Issues 与 Pull Requests并将电子邮件通知设置为仅在参与、提及和自定义时接收——既避免手动翻找又不被海量通知淹没。结语从 Issue 的分类审查、PR 的分级审批到构建测试流水线与自动化发布p5.js 的维护体系始终围绕两个原则运转让每项变更都有迹可循Issue 驱动、让每次合入都有质量保障双人审查 CI。对照本文给出的仓库文件——Issue 模板、PR 模板、rolldown.config.js、vitest.config.js、CI 工作流、stewards.yml 与发布流程文档——你可以逐项验证并复用这套流程无论是作为新 steward 快速上手还是作为贡献者理解 PR 被如何评审都能从中找到明确答案。若想进一步了解本地开发与构建命令的实操细节可继续阅读贡献者指南。【免费下载链接】p5.jsp5.js is a client-side JS platform that empowers artists, designers, students, and anyone to learn to code and express themselves creatively on the web. It is based on the core principles of Processing. Looking for p5.js 2.0? http://beta.p5js.org项目地址: https://gitcode.com/GitHub_Trending/p5/p5.js创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
