p5.js 版本发布流程全解析从语义化版本、np 自动化到 GitHub Actions 流水线【免费下载链接】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本篇技术指南以 contributor_docs/ko/release_process.md 为骨架系统讲解 p5.js 从源码改动到正式发版的完整链路语义化版本策略、发布前置条件、npm run release的核心机制以及当前仓库已迁移到的 GitHub Actions 全自动发布流水线。读完本文你将掌握 p5.js 的版本号规则、发布命令与底层执行细节并能在本地安全地演练发布流程而不会误推任何远程仓库。一、发布流程的核心原则语义化版本SemVerp5.js 严格遵循 SemVer语义化版本模式版本号采用주:부:수即主:次:补丁MAJOR:MINOR:PATCH三段式结构MAJOR主版本存在不兼容的 API 变更时递增MINOR次版本以向后兼容的方式新增功能时递增PATCH补丁向后兼容的缺陷修复时递增。这一约定在 contributor_docs/ko/release_process.md 与英文版 contributor_docs/release_process.md 中均有明确记载且实际落地在仓库的版本号中——package.json 当前的version字段即为2.3.1。任何一次发布本质上都是把这一版本号向前推进并让构建产物、NPM 包、GitHub Release、Bower 仓库与官网参考资料全部同步到新版本。二、发布前置要求与环境准备发布前需要确认以下条件全部满足任何一项缺失都会导致流程中断要求说明验证方式Git、Node.js、NPM系统需已安装三者的可用版本git --version、node -v、npm -vNPM CLI 登录状态发布账号必须已登录且对p5包拥有发布权限npm whoami能打印当前用户名远程仓库推送权限需要能够向 p5.js 主仓库推送提交与标签—高带宽网络整个流程涉及大量下载/拉取/推送总量约~190MB—在旧版np流程中NPM 登录是硬性前提而在当前 GitHub Actions 流水线下本地的 NPM 登录被仓库级 Secrets 取代但概念一脉相承NPM_TOKEN具有读取与发布权限的 NPM 访问令牌其所属账号需对 NPM 上的p5项目有发布权限ACCESS_TOKEN个人访问令牌PAT需能访问p5.js、p5.js-website、p5.js-release三个仓库scope 仅需repo与workflow官方建议使用组织级账号并最小化写权限。这两个 Secrets 在 .github/workflows/release-workflow-v1.yml 与 .github/workflows/release-workflow-v2.yml 的文件头注释中明确标注为必需项# Requires secrets NPM_TOKEN and ACCESS_TOKEN to be set并在工作流内通过${{ secrets.NPM_TOKEN }}、${{ secrets.ACCESS_TOKEN }}引用。三、如何发起一次发布3.1 旧版文档记载npm run release按 contributor_docs/ko/release_process.md 的记载历史上发布只需一条命令$ npm run release执行后构建阶段先运行随后跟随np提供的交互式提示完成整个流程构建阶段会执行 grunt 任务生成库的 zip 压缩包、向 Bower 发布、并把最新版参考文档发布到 p5.js 官网。npm run release本质上是运行np的别名旧版配置中np会先创建子进程执行grunt release-p5。需要指出的是当前仓库的 package.json 中已不再包含release脚本也找不到prepublishOnly与 grunt 相关配置——scripts 仅保留build、dev、test、lint、docs、generate-types等。这说明 p5.js 的发布主流程已从本地np工具迁移到 CI 自动化下文将给出当前仓库的实际证据。3.2 当前流程打标签触发 GitHub Actions英文版 contributor_docs/release_process.md 给出了现行做法——所有实际发布步骤全部在 GitHub Actions CI 上运行本地只需三步$ git checkout main $ npm version [major|minor|patch] # 选择合适的版本标签 $ git push origin main $ git push origin v2.3.2 # 替换为上面刚生成的版本号npm version [major|minor|patch]会同时完成三件事按 SemVer 规则递增 package.json 中的version字段、创建对应的 git 提交、打上形如v2.3.2的注解标签。随后推送标签即触发 CI。仓库中存在两套并行的发布工作流按版本主号分流.github/workflows/release-workflow-v1.ymlNew p5.js v1 release监听v1.*.*与v1.*.*-*标签.github/workflows/release-workflow-v2.ymlNew p5.js 2.x release监听v2.*.*与v2.*.*-*标签。两套工作流都运行在ubuntu-latest使用 Node.js 22并在第一步通过actions/checkout拉取代码。它们共同印证了英文文档中“GitHub Action 由npm version ___创建的v*.*.*标签触发”的描述。四、发布过程中实际发生的事Whats actually happening4.1 旧版np的完整执行链按韩文原文档的逐条记载npm run release触发的np会依次执行本地仓库体检np检查本地仓库并准备发布配置继续执行前不允许存在任何未提交的改动dirty working tree 会中止发布重装依赖并测试np重新安装node_modules并执行npm test跑一遍完整测试版本递增根据最初选择的选项major/minor/patch对版本号做 bump失败回滚若以上任何一步失败仓库会回退到执行npm run release之前的初始状态保证半途失败不会留下脏状态构建文档与库执行package.json中prepublishOnly声明的任务旧配置为grunt prerelease用更新后的版本号重新构建文档与库文件发布 NPM 包只有package.json的files字段中列出的文件会被发布到 NPM——这一点在 package.json 中得到印证其files字段精确列出了dist/**、license.txt、lib/p5.js、lib/p5.min.js、lib/p5.esm.js、lib/p5.webgpu*.js、translations/**、types/**等发布白名单推送 git 远端将本地新增的标签与提交推送到 git remote创建 GitHub 草稿 Release在 GitHub 上生成带可编辑 changelog 的草稿版本打包p5.zip在lib目录含空示例中生成p5.zip作为 GitHub Release 草稿的附件上传流程结束后会打开指向release/的窗口其中包含需要作为 GitHub Release 组成部分上传的全部文件同步 Bower 仓库把新构建的库推送到 p5.js-releaseBower 分发仓库同步官网参考文档把新构建的参考文档推送到 p5.js-website。4.2 当前 GitHub Actions 流水线的实际步骤对照 .github/workflows/release-workflow-v2.yml 的源码现行流水线将上述环节几乎全部搬进了 CI分为四个阶段阶段 1环境准备与质量门禁- uses: actions/setup-node... # node-version: 22 - name: Install dependencies run: npm ci # 干净安装CItrue - name: Run test run: npm test -- --projectunit-tests - name: Run build run: npm run build - name: Generate types run: npm run generate-types - name: test TypeScript types run: npm run test:types流水线先用npm ci精确重装依赖再依次执行单元测试、npm run build构建、npm run generate-types生成类型声明、npm run test:types校验 TS 类型——相当于把旧流程中“重装依赖 npm test”的质量门禁扩展为“测试 构建 类型校验”四重检查。工作流还会用cut -c 2-从github.ref_name如v2.3.2中剥离前导v得到纯版本号2.3.2供后续步骤使用。阶段 2准备发布文件- run: mkdir release mkdir p5 cp -r ./lib/* p5/ - uses: TheDoctor0/zip-release... with: type: zip filename: release/p5.zip path: ./p5/* - run: cp lib/p5.js lib/p5.min.js lib/p5.esm.js release/这一步对应旧流程中的“zip 打包”把lib/下全部产物复制进p5/目录压缩为release/p5.zip再把p5.js、p5.min.js、p5.esm.js单独复制到release/。v1 工作流release-workflow-v1.yml额外还会带上lib/addons/p5.sound.js与p5.sound.min.js。当前库的构建产物由 rolldown.config.js 定义它基于 rolldown 产出lib/p5.jsIIFE、lib/p5.min.js压缩、lib/p5.esm.js/p5.esm.min.jsESM、WebGPU 附加模块及dist/下的 ESM 源码构建并在文件头 banner 中内嵌版本号与构建日期。阶段 3创建 GitHub Release 并发布 NPM- name: Create GitHub release uses: softprops/action-gh-release... with: draft: true prerelease: ${{ steps.semver.outputs.is-prerelease true }} files: release/* generate_release_notes: true - name: Publish to NPM uses: JS-DevTools/npm-publish... with: tag: ${{ steps.semver.outputs.is-prerelease ! true latest || beta }}这里与旧流程一一对应draft: true生成草稿 Release由维护者随后审阅 changelog 再正式发布、generate_release_notes: true自动生成变更说明NPM 发布通过npm-publishaction 完成。工作流对预发布版本做了专门处理——凡是标签包含-rc如v2.4.0-rc.1Release 会标记为 prereleaseNPM 上的发布 tag 自动切换为beta而非latest。阶段 4同步官网与 Bower对于非预发布版本工作流会克隆processing/p5.js-website依次执行npm run build:p5-version、build:contributor-docs、build:contributors、build:reference、build:search重建官网数据然后以github-actions[bot]身份提交并推送Update p5.js to v2.x.x。v1 工作流额外还会克隆processing/p5.js-releaseBower 仓库把lib/*.js与lib/addons/*复制进bower/lib/后推送到master分支——这正是旧流程第 10、11 步的 CI 化版本。注意 v2 工作流已不再包含 Bower 同步步骤只更新官网。值得注意英文文档 contributor_docs/release_process.md 强调了一条设计原则——尽量把所有只在发布时运行的步骤集中到 CI 环境如果需要新增仅发布时执行的步骤应定义在 CI 工作流中而不是写进构建配置。这是理解整套流水线演进的关键。4.3 失败回滚与半途中断旧版np自带“失败即回滚”保护任何一步失败都会把仓库恢复到执行发布命令前的状态。在 CI 版本中这一保障由工作流的步骤级失败语义替代——npm test、构建或类型校验任一失败后续步骤都不会执行NPM 与 GitHub Release 均不会产生新版本仓库代码也始终保持干净发布只依赖已推送的标签不产生本地副作用。五、如何安全地测试发布流程Testing发布流程涉及推送、发布等高风险操作直接跑完整发布来“试一次”显然不可取。原文档给出了两种演练路径与当前 CI 架构结合后更加清晰。5.1 有远程推送权限npm run release---preview$ npm run release---previewpreview模式会以简化的方式走一遍发布流程不会改动任何 git 跟踪文件也不会向任何远程仓库推送适合在本地验证流程各环节是否可跑通。5.2 无远程推送权限命名空间包名技巧没有推送权限时需要先把 package.json 中的name字段改成命名空间形式例如{ name: username/p5 }然后提交这一改动照常执行npm run release---preview。执行过程中np会提示不要将包发布到 NPM 上对应的命名空间——只要选择不发布线上就不会出现任何新包。如果修改了name字段还可以进一步运行完整发布测试$ npm run release并可通过附加参数指定 Bower 发布与官网同步时克隆、推送的目标$ npm run release -- --bowerReleaserusername5.3 已知坑np的命名空间发布 Bug原文档明确记录了一个版本相关的已知问题np6.2.0 存在阻止使用命名空间包名scoped package name发布 Release 的 bug对应 upstream issue #508。因此如果必须测试上述命名空间场景需要把np降级到5.2.1否则流程会在发布阶段直接失败。5.4 针对当前 CI 架构的测试建议英文版文档补充了 CI 时代的测试思路由于发布步骤全部运行在 CI本地测试可以借助 act 在本地执行 GitHub Actions 工作流这也是工作流开发阶段的实测方式但需要临时改动 workflow 定义且因本地缺少跑 Chrome 测试的系统依赖测试步骤往往无法执行需按报错提示用apt补装缺失的系统包同时建议把推送到远程仓库的步骤注释掉避免演练时误推意外改动。这一点在 .github/workflows/release-workflow-v1.yml 等文件中同样适用——工作流中所有使用ACCESS_TOKEN的 checkout/push 步骤都应被注释。另外仓库还维护着一条与正式发布并行的“每日预览”通道.github/workflows/continuous-release.yml 会在main分支的每次 push 及 PR 上运行npx pkg-pr-new publish把最新构建发布到 pkg.pr.new 预览服务供社区提前试用main分支的最新代码——这可以看作是发布流程之外的低风险灰度验证手段。六、发布后的监控与验证发布命令执行完毕后可从以下入口逐层确认发布结果GitHub Actions 页面在仓库 Actions 标签页查找名为New p5.js release的任务release-workflow-v2.yml 的 job 名为Release点击进入可查看详细的步骤日志图中即展示了v1.7.0标签触发任务的执行状态与耗时GitHub Release 页面任务完成后 GitHub 上会生成新版本草稿应审阅自动生成的 changelog必要时手动编辑再正式发布publishNPM 页面确认p5包已更新到最新版本号官网 Downloads 页面官网仓库自身的构建与部署任务完成后其下载页会显示最新版本号CDN 同步各 CDN 通常需要一到两天才会自动从 NPM 拉取并更新无需任何额外操作。七、总结从 contributor_docs/ko/release_process.md 记载的npm run releasenp grunt时代到当前由 .github/workflows/release-workflow-v1.yml 与 .github/workflows/release-workflow-v2.yml 承接的全自动 CI 发布p5.js 发布流程的目标状态始终未变语义化版本号 测试门禁 构建产物 NPM/GitHub/Bower/官网四方同步。理解这套流程既能帮助你作为维护者安全地发起与验证一次发布也能让你在查看 Release 与 NPM 包时清楚每一步产物从何而来、由哪份配置决定。如需深入源码可继续阅读 package.json 的files白名单、rolldown.config.js 的产物定义以及两套发布工作流的完整步骤。【免费下载链接】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 版本发布流程全解析：从语义化版本、np 自动化到 GitHub Actions 流水线
p5.js 版本发布流程全解析从语义化版本、np 自动化到 GitHub Actions 流水线【免费下载链接】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本篇技术指南以 contributor_docs/ko/release_process.md 为骨架系统讲解 p5.js 从源码改动到正式发版的完整链路语义化版本策略、发布前置条件、npm run release的核心机制以及当前仓库已迁移到的 GitHub Actions 全自动发布流水线。读完本文你将掌握 p5.js 的版本号规则、发布命令与底层执行细节并能在本地安全地演练发布流程而不会误推任何远程仓库。一、发布流程的核心原则语义化版本SemVerp5.js 严格遵循 SemVer语义化版本模式版本号采用주:부:수即主:次:补丁MAJOR:MINOR:PATCH三段式结构MAJOR主版本存在不兼容的 API 变更时递增MINOR次版本以向后兼容的方式新增功能时递增PATCH补丁向后兼容的缺陷修复时递增。这一约定在 contributor_docs/ko/release_process.md 与英文版 contributor_docs/release_process.md 中均有明确记载且实际落地在仓库的版本号中——package.json 当前的version字段即为2.3.1。任何一次发布本质上都是把这一版本号向前推进并让构建产物、NPM 包、GitHub Release、Bower 仓库与官网参考资料全部同步到新版本。二、发布前置要求与环境准备发布前需要确认以下条件全部满足任何一项缺失都会导致流程中断要求说明验证方式Git、Node.js、NPM系统需已安装三者的可用版本git --version、node -v、npm -vNPM CLI 登录状态发布账号必须已登录且对p5包拥有发布权限npm whoami能打印当前用户名远程仓库推送权限需要能够向 p5.js 主仓库推送提交与标签—高带宽网络整个流程涉及大量下载/拉取/推送总量约~190MB—在旧版np流程中NPM 登录是硬性前提而在当前 GitHub Actions 流水线下本地的 NPM 登录被仓库级 Secrets 取代但概念一脉相承NPM_TOKEN具有读取与发布权限的 NPM 访问令牌其所属账号需对 NPM 上的p5项目有发布权限ACCESS_TOKEN个人访问令牌PAT需能访问p5.js、p5.js-website、p5.js-release三个仓库scope 仅需repo与workflow官方建议使用组织级账号并最小化写权限。这两个 Secrets 在 .github/workflows/release-workflow-v1.yml 与 .github/workflows/release-workflow-v2.yml 的文件头注释中明确标注为必需项# Requires secrets NPM_TOKEN and ACCESS_TOKEN to be set并在工作流内通过${{ secrets.NPM_TOKEN }}、${{ secrets.ACCESS_TOKEN }}引用。三、如何发起一次发布3.1 旧版文档记载npm run release按 contributor_docs/ko/release_process.md 的记载历史上发布只需一条命令$ npm run release执行后构建阶段先运行随后跟随np提供的交互式提示完成整个流程构建阶段会执行 grunt 任务生成库的 zip 压缩包、向 Bower 发布、并把最新版参考文档发布到 p5.js 官网。npm run release本质上是运行np的别名旧版配置中np会先创建子进程执行grunt release-p5。需要指出的是当前仓库的 package.json 中已不再包含release脚本也找不到prepublishOnly与 grunt 相关配置——scripts 仅保留build、dev、test、lint、docs、generate-types等。这说明 p5.js 的发布主流程已从本地np工具迁移到 CI 自动化下文将给出当前仓库的实际证据。3.2 当前流程打标签触发 GitHub Actions英文版 contributor_docs/release_process.md 给出了现行做法——所有实际发布步骤全部在 GitHub Actions CI 上运行本地只需三步$ git checkout main $ npm version [major|minor|patch] # 选择合适的版本标签 $ git push origin main $ git push origin v2.3.2 # 替换为上面刚生成的版本号npm version [major|minor|patch]会同时完成三件事按 SemVer 规则递增 package.json 中的version字段、创建对应的 git 提交、打上形如v2.3.2的注解标签。随后推送标签即触发 CI。仓库中存在两套并行的发布工作流按版本主号分流.github/workflows/release-workflow-v1.ymlNew p5.js v1 release监听v1.*.*与v1.*.*-*标签.github/workflows/release-workflow-v2.ymlNew p5.js 2.x release监听v2.*.*与v2.*.*-*标签。两套工作流都运行在ubuntu-latest使用 Node.js 22并在第一步通过actions/checkout拉取代码。它们共同印证了英文文档中“GitHub Action 由npm version ___创建的v*.*.*标签触发”的描述。四、发布过程中实际发生的事Whats actually happening4.1 旧版np的完整执行链按韩文原文档的逐条记载npm run release触发的np会依次执行本地仓库体检np检查本地仓库并准备发布配置继续执行前不允许存在任何未提交的改动dirty working tree 会中止发布重装依赖并测试np重新安装node_modules并执行npm test跑一遍完整测试版本递增根据最初选择的选项major/minor/patch对版本号做 bump失败回滚若以上任何一步失败仓库会回退到执行npm run release之前的初始状态保证半途失败不会留下脏状态构建文档与库执行package.json中prepublishOnly声明的任务旧配置为grunt prerelease用更新后的版本号重新构建文档与库文件发布 NPM 包只有package.json的files字段中列出的文件会被发布到 NPM——这一点在 package.json 中得到印证其files字段精确列出了dist/**、license.txt、lib/p5.js、lib/p5.min.js、lib/p5.esm.js、lib/p5.webgpu*.js、translations/**、types/**等发布白名单推送 git 远端将本地新增的标签与提交推送到 git remote创建 GitHub 草稿 Release在 GitHub 上生成带可编辑 changelog 的草稿版本打包p5.zip在lib目录含空示例中生成p5.zip作为 GitHub Release 草稿的附件上传流程结束后会打开指向release/的窗口其中包含需要作为 GitHub Release 组成部分上传的全部文件同步 Bower 仓库把新构建的库推送到 p5.js-releaseBower 分发仓库同步官网参考文档把新构建的参考文档推送到 p5.js-website。4.2 当前 GitHub Actions 流水线的实际步骤对照 .github/workflows/release-workflow-v2.yml 的源码现行流水线将上述环节几乎全部搬进了 CI分为四个阶段阶段 1环境准备与质量门禁- uses: actions/setup-node... # node-version: 22 - name: Install dependencies run: npm ci # 干净安装CItrue - name: Run test run: npm test -- --projectunit-tests - name: Run build run: npm run build - name: Generate types run: npm run generate-types - name: test TypeScript types run: npm run test:types流水线先用npm ci精确重装依赖再依次执行单元测试、npm run build构建、npm run generate-types生成类型声明、npm run test:types校验 TS 类型——相当于把旧流程中“重装依赖 npm test”的质量门禁扩展为“测试 构建 类型校验”四重检查。工作流还会用cut -c 2-从github.ref_name如v2.3.2中剥离前导v得到纯版本号2.3.2供后续步骤使用。阶段 2准备发布文件- run: mkdir release mkdir p5 cp -r ./lib/* p5/ - uses: TheDoctor0/zip-release... with: type: zip filename: release/p5.zip path: ./p5/* - run: cp lib/p5.js lib/p5.min.js lib/p5.esm.js release/这一步对应旧流程中的“zip 打包”把lib/下全部产物复制进p5/目录压缩为release/p5.zip再把p5.js、p5.min.js、p5.esm.js单独复制到release/。v1 工作流release-workflow-v1.yml额外还会带上lib/addons/p5.sound.js与p5.sound.min.js。当前库的构建产物由 rolldown.config.js 定义它基于 rolldown 产出lib/p5.jsIIFE、lib/p5.min.js压缩、lib/p5.esm.js/p5.esm.min.jsESM、WebGPU 附加模块及dist/下的 ESM 源码构建并在文件头 banner 中内嵌版本号与构建日期。阶段 3创建 GitHub Release 并发布 NPM- name: Create GitHub release uses: softprops/action-gh-release... with: draft: true prerelease: ${{ steps.semver.outputs.is-prerelease true }} files: release/* generate_release_notes: true - name: Publish to NPM uses: JS-DevTools/npm-publish... with: tag: ${{ steps.semver.outputs.is-prerelease ! true latest || beta }}这里与旧流程一一对应draft: true生成草稿 Release由维护者随后审阅 changelog 再正式发布、generate_release_notes: true自动生成变更说明NPM 发布通过npm-publishaction 完成。工作流对预发布版本做了专门处理——凡是标签包含-rc如v2.4.0-rc.1Release 会标记为 prereleaseNPM 上的发布 tag 自动切换为beta而非latest。阶段 4同步官网与 Bower对于非预发布版本工作流会克隆processing/p5.js-website依次执行npm run build:p5-version、build:contributor-docs、build:contributors、build:reference、build:search重建官网数据然后以github-actions[bot]身份提交并推送Update p5.js to v2.x.x。v1 工作流额外还会克隆processing/p5.js-releaseBower 仓库把lib/*.js与lib/addons/*复制进bower/lib/后推送到master分支——这正是旧流程第 10、11 步的 CI 化版本。注意 v2 工作流已不再包含 Bower 同步步骤只更新官网。值得注意英文文档 contributor_docs/release_process.md 强调了一条设计原则——尽量把所有只在发布时运行的步骤集中到 CI 环境如果需要新增仅发布时执行的步骤应定义在 CI 工作流中而不是写进构建配置。这是理解整套流水线演进的关键。4.3 失败回滚与半途中断旧版np自带“失败即回滚”保护任何一步失败都会把仓库恢复到执行发布命令前的状态。在 CI 版本中这一保障由工作流的步骤级失败语义替代——npm test、构建或类型校验任一失败后续步骤都不会执行NPM 与 GitHub Release 均不会产生新版本仓库代码也始终保持干净发布只依赖已推送的标签不产生本地副作用。五、如何安全地测试发布流程Testing发布流程涉及推送、发布等高风险操作直接跑完整发布来“试一次”显然不可取。原文档给出了两种演练路径与当前 CI 架构结合后更加清晰。5.1 有远程推送权限npm run release---preview$ npm run release---previewpreview模式会以简化的方式走一遍发布流程不会改动任何 git 跟踪文件也不会向任何远程仓库推送适合在本地验证流程各环节是否可跑通。5.2 无远程推送权限命名空间包名技巧没有推送权限时需要先把 package.json 中的name字段改成命名空间形式例如{ name: username/p5 }然后提交这一改动照常执行npm run release---preview。执行过程中np会提示不要将包发布到 NPM 上对应的命名空间——只要选择不发布线上就不会出现任何新包。如果修改了name字段还可以进一步运行完整发布测试$ npm run release并可通过附加参数指定 Bower 发布与官网同步时克隆、推送的目标$ npm run release -- --bowerReleaserusername5.3 已知坑np的命名空间发布 Bug原文档明确记录了一个版本相关的已知问题np6.2.0 存在阻止使用命名空间包名scoped package name发布 Release 的 bug对应 upstream issue #508。因此如果必须测试上述命名空间场景需要把np降级到5.2.1否则流程会在发布阶段直接失败。5.4 针对当前 CI 架构的测试建议英文版文档补充了 CI 时代的测试思路由于发布步骤全部运行在 CI本地测试可以借助 act 在本地执行 GitHub Actions 工作流这也是工作流开发阶段的实测方式但需要临时改动 workflow 定义且因本地缺少跑 Chrome 测试的系统依赖测试步骤往往无法执行需按报错提示用apt补装缺失的系统包同时建议把推送到远程仓库的步骤注释掉避免演练时误推意外改动。这一点在 .github/workflows/release-workflow-v1.yml 等文件中同样适用——工作流中所有使用ACCESS_TOKEN的 checkout/push 步骤都应被注释。另外仓库还维护着一条与正式发布并行的“每日预览”通道.github/workflows/continuous-release.yml 会在main分支的每次 push 及 PR 上运行npx pkg-pr-new publish把最新构建发布到 pkg.pr.new 预览服务供社区提前试用main分支的最新代码——这可以看作是发布流程之外的低风险灰度验证手段。六、发布后的监控与验证发布命令执行完毕后可从以下入口逐层确认发布结果GitHub Actions 页面在仓库 Actions 标签页查找名为New p5.js release的任务release-workflow-v2.yml 的 job 名为Release点击进入可查看详细的步骤日志图中即展示了v1.7.0标签触发任务的执行状态与耗时GitHub Release 页面任务完成后 GitHub 上会生成新版本草稿应审阅自动生成的 changelog必要时手动编辑再正式发布publishNPM 页面确认p5包已更新到最新版本号官网 Downloads 页面官网仓库自身的构建与部署任务完成后其下载页会显示最新版本号CDN 同步各 CDN 通常需要一到两天才会自动从 NPM 拉取并更新无需任何额外操作。七、总结从 contributor_docs/ko/release_process.md 记载的npm run releasenp grunt时代到当前由 .github/workflows/release-workflow-v1.yml 与 .github/workflows/release-workflow-v2.yml 承接的全自动 CI 发布p5.js 发布流程的目标状态始终未变语义化版本号 测试门禁 构建产物 NPM/GitHub/Bower/官网四方同步。理解这套流程既能帮助你作为维护者安全地发起与验证一次发布也能让你在查看 Release 与 NPM 包时清楚每一步产物从何而来、由哪份配置决定。如需深入源码可继续阅读 package.json 的files白名单、rolldown.config.js 的产物定义以及两套发布工作流的完整步骤。【免费下载链接】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），仅供参考