开发工具前端【免费下载链接】speedscope A fast, interactive web-based viewer for performance profiles.项目地址https://gitcode.com/gh_mirrors/sp/speedscope点击查看免费下载本文面向 speedscope 仓库的管理员与维护者完整梳理从发布前测试到创建并发布新版本再到验证发布结果的整套运维流程包括 mock 安装测试脚本的原理、自动化发布脚本publish-and-deploy.sh的七步执行链路、CLI 验证要点以及网站gh-pages部署的底层机制。读完本文你将能够独立完成一次 speedscope 版本的发布、回滚前的验证与发布后的核验。文档定位这份管理员指南覆盖什么README-ADMINS.md 是仓库中专门面向管理员admin的过程文档与面向普通用户的 README.md 职责不同后者讲解如何导入 profile、如何使用视图与快捷键前者聚焦如何安全地把一个新版本发布出去。文档首先声明了一个重要前提发布流程假定在 macOS 上运行。原文明确写到在 Linux 上probably works可能可用而在 Windows 上almost definitely does not work几乎肯定不可用。这意味着管理员在非 macOS 环境执行发布前应优先在 macOS 机器或等效的 Unix 环境中进行尤其是下文会提到的npm pack、tar解包、临时目录路径等步骤与 Unix 工具链强相关。整个发布流程由一组位于 scripts 目录的 bash 脚本支撑它们是本文所有命令的底层实现脚本职责prepare-test-installation.sh模拟一次 npm 发布并安装用于发布前冒烟测试publish-and-deploy.sh一键执行版本号提升、变更日志、git 提交打标签、npm 发布、网站部署、zip 构建deploy.sh将构建产物推送到 gh-pages 分支完成网站部署prepare-zip-file.sh基于 npm 包内容生成可独立使用的 zip 版本print-changelog-update.sh根据最近一次 tag 的 git 提交记录生成变更日志片段prepack.sh构建 release 产物--protocol http或fileci.shCI 阶段执行的类型检查、lint、测试覆盖率检查第一步发布前测试Test the releasespeedscope 的所有自动化测试都由 CI 承担详见下文与 CI 的衔接一节因此发布前只需要做少量冒烟检查sanity checks确认构建与发布相关的机器链路本身工作正常。运行模拟安装脚本在仓库根目录执行scripts/prepare-test-installation.sh该命令会做一次mock 发布与安装mock publish installation以确认即将发布的版本确实可用。命令结束时终端会打印一条cd指令提示切换到测试安装目录输出形如Run the following command to switch into the test directory cd /var/folders/l0/qtd9z14973s2tw81vmzwkyp00000gp/T/speedscope-test-installation.9Ssdd2PZ/package具体路径由mktemp动态生成每次运行都不同。脚本背后mock publish 的完整链路从 prepare-test-installation.sh 的源码可以看到这个模拟发布到底做了什么set -euxo pipefail TESTDIRmktemp -d -t speedscope-test-installation # 1. 创建临时目录 PACKEDNAMEnpm pack | tail -n1 # 2. 本地打包生成 .tgz mv $PACKEDNAME $TESTDIR # 3. 把包移入临时目录 cd $TESTDIR tar -xvvf $PACKEDNAME # 4. 解包 cd package npm install # 5. 安装依赖 set x echo echo Run the following command to switch into the test directory echo cd $TESTDIR/package关键点在于脚本用npm pack本地打包替代了npm publish真实发布到 npm registry再用tar解包、npm install复刻了用户通过npm install -g speedscope会经历的安装过程。这样可以在不污染 npm registry 的前提下完整验证打包 → 安装 → 运行链路。set -euxo pipefail保证任何一步失败都会立即中断避免带病发布。该脚本依赖 package.json 中的files字段约定——只有bin/cli.mjs、dist/release/**排除*.map会被打进包这也决定了冒烟测试能验证的范围。手工冒烟检查步骤执行上面打印的cd命令进入测试目录后按文档要求做两项检查运行 CLI 并导入本地文件执行bin/cli.mjs浏览器会打开一份 speedscope 副本。点击页面上的 browse 按钮从磁盘导入一个 profile 文件确认导入功能正常。测试命令行参数直接加载执行bin/cli.mjs dist/release/perf-vertx*此时浏览器应立即打开 speedscope并且 perf-vertx 文件立即加载完成无需再手动导入。关于第二个检查项中的dist/release/perf-vertx*通配符从源码看speedscope 内置了一份名为perf-vertx-stacks-01-collapsed-all.txt的示例 profile位于 sample/profiles/stackcollapse/perf-vertx-stacks-01-collapsed-all.txt并且在应用入口 src/views/application.tsx 中通过loadExample直接fetch该文件作为演示数据。构建产物目录dist/release/中会包含对应的发布版示例文件因此这条命令既能验证 CLI 的参数加载路径也能顺带验证示例数据在发布包中是否完整。CLI 加载机制的源码佐证CLI 本体是 bin/cli.mjs它在package.json中被声明为bin入口。当传入文件路径时它会把文件内容转为 base64写入一个临时.js文件再以#localProfilePathjs 路径的 hash 参数打开dist/release/index.html浏览器端在 src/views/application.tsx 中读取hashParams.localProfilePath加载该临时脚本并调用loadFileFromBase64(filename, base64source)完成导入hash 参数解析逻辑见 src/lib/hash-params.ts并有对应测试 src/lib/hash-params.test.ts 覆盖#localProfilePath...的解析。此外 CLI 还支持以-作为路径参数从 stdin 读取cat /path/to/profile | speedscope -以及--help/-h、--version/-v两个标志。由于 macOS 的open与 Windows 的start会忽略 URL 中的 hash 参数CLI 在darwin/win32平台还会额外生成一个临时 HTML 重定向页来绕开该问题——这也再次印证了发布流程假定 macOS的文档前提。第二步创建并发布新版本Create publish the new release发布前置条件执行发布前需要确认以下三项就绪安装并认证 GitHub CLI运行gh auth status确认已登录。npm 身份可用运行npm whoami确认 npm 账号可用。浏览器登录 npm在默认浏览器中确保已登录 npm 账号——文档特别提醒若未登录在 npm publish 过程中打开 authenticate 链接时会看到 404 页面该提醒来自 CHANGELOG 中 1.18.0 的 #457 变更专门为 npm 登录指引补充。执行发布脚本确认就绪后运行scripts/publish-and-deploy.sh脚本接受一个必填参数用于指定版本号的提升方式。从 publish-and-deploy.sh 源码看参数取值可以是minor、patch或直接指定完整版本号Usage: $0 minor | patch | version e.g. $0 patch七步执行链路拆解从脚本源码scripts/publish-and-deploy.sh可以看到一次发布实际上是如下 7 个环节的串联类型检查node_modules/.bin/tsc --noEmit与npm run typecheck等价单元测试npm run jest实际由 test-setup.sh 先解压测试用 zip 样本再运行 Jest提升版本号但不提交npm version $version_arg --no-git-tag-version --no-commit-hooks同时更新package.json与package-lock.json但不立即创建 commit 或 tag更新变更日志调用 print-changelog-update.sh 生成自上一个 tag 以来的提交记录摘要格式与 CHANGELOG.md 保持一致## [版本号] - 日期带 PR 编号与作者署名并前置写入 CHANGELOG.md提交并打标签git add CHANGELOG.md package.json package-lock.json以版本号为 commit message创建v$version形式的 tag然后git push与git push --tags发布到 npmnpm publish部署网站 构建独立 zipnpm run deploy对应 deploy.sh再调用 prepare-zip-file.sh 生成dist/release/speedscope-$version.zip。收尾在 GitHub 创建 Release脚本执行完毕后并不会自动创建 GitHub Release而是打印出人工操作指引包括需要访问的 GitHub Releases 新建页面tag: v$versiontitle: v$versionattachment: dist/release/speedscope-$version.zip以及本次生成的变更日志内容。脚本源码中注释说明这一环节几乎但并非完全可以用gh release create自动化脚本里甚至保留了可参考的命令样例之所以保留人工步骤是因为两个未解决的问题——--attach标志的退出行为不理想且不希望 Release 注释包含 CHANGELOG 中的版本号与日期。因此在当前版本中管理员仍需在网页上手工创建 Release 并上传 zip。发布时自动执行的构建脚本第 7 步的 zip 构建依赖 prepare-zip-file.sh它从 npm registry 拉取刚发布的包npm pack speedscope解包后把dist/release/**拷贝进speedscope/目录附带 LICENSE 与一个说明index.html用途的 README最后打包为speedscope-version.zip放到dist/release/。发布构建本身由 prepack.sh 完成对应npm run prepack使用--protocol file生成可直接双击打开的独立版本而 deploy.sh 走的是./scripts/prepack.sh --outdir $OUTDIR --protocol http即面向 HTTP 服务的版本。prepack.sh还会在产物目录写入release.txt记录 npm 包名、构建日期与git rev-parse HEAD以及file-format-schema.json由 generate-file-format-schema-json.js 生成便于事后定位具体构建对应的 commit。第三步验证发布结果Verifying the release验证 npm 包可用发布完成后从最终用户视角验证 npm 包npm install -g speedscope随后验证两种调用方式无参数启动直接运行speedscope浏览器应打开 speedscope 界面带参数直接加载 profile运行speedscope sample/profiles/stackcollapse/simple.txt浏览器应立即打开并加载该 profile。仓库中的 sample/profiles/stackcollapse/simple.txt 是标准的 stackcollapse 格式文本每行一个;分隔的调用栈加权重数值例如a;b;c 1 a;b;c 1 a;b;d 4 a;b;c 3 a;b 5正是验证 CLI 加载链路的最小样例。此验证与发布前测试中的bin/cli.mjs dist/release/perf-vertx*形成闭环前者验证源码包后者验证 npm 安装后的全局命令。验证网站部署完成npm 发布成功只代表包可用网站部署是独立的一条链路。打开 https://www.speedscope.app/ 后查看浏览器控制台中显示的版本号确认其与本次发布的版本一致即表示 gh-pages 部署完成。网站部署的机制见 deploy.sh脚本先以--protocol http构建产物到dist/http-release再对仓库做一次--depth 1的浅克隆切到gh-pages分支把构建产物拷贝进去、写入www.speedscope.app的 CNAME 记录随后在本地http.server 4444启动服务器供人工验证按CtrlC后确认输入yes才git push origin HEAD:gh-pages完成部署。这也解释了为什么验证时要以控制台版本号为准——部署内容来自本次构建产物。与 CI 的衔接发布前的自动化测试保障来自 CI。仓库的 scripts/ci.sh对应npm test依次执行npm run typecheck npm run lint npm run coverage node scripts/generate-file-format-schema-json.js /dev/null即类型检查tsc --noEmit、ESLint、带覆盖率统计的 Jest 测试以及文件格式 schema 的生成校验。其中 jest 配置package.json使用 jsdom 环境、ts-jest/esbuild-jest转译并会把 Java Flight Recorder 的 wasm 模块 mock 掉jfrview_bg.wasm→ src/import/java-flight-record.mock.ts。发布脚本内部复用了其中tsc与jest两步相当于发布前再跑一遍关键检查的双保险。关键脚本速查阶段命令/脚本产出发布前测试scripts/prepare-test-installation.sh临时目录中的可运行安装包发布scripts/publish-and-deploy.sh patch\|minor\|version新 tag、npm 包、gh-pages 部署、dist/release/speedscope-v.zip变更日志scripts/print-changelog-update.sh version可前置到 CHANGELOG.md 的更新片段网站部署npm run deploydeploy.shgh-pages 分支更新zip 构建scripts/prepare-zip-file.shdist/release/speedscope-v.zipCInpm testci.sh类型检查、lint、覆盖率、schema 生成注意事项与常见问题平台限制整套流程假定 macOSLinux 可能可用、Windows 几乎不可用。CLI 在 Windows 上需要wait: true打开浏览器见 bin/cli.mjs且 macOS/Windows 均需要临时 HTML 重定向来携带 hash 参数这些平台差异是假定 macOS的主要原因之一。版本参数发布脚本只接受patch、minor或完整版本号三种参数传入其他值会直接报错退出。顺序不可颠倒必须先通过发布前测试与手工冒烟检查再执行发布脚本npm publish一旦执行即不可撤回所以冒烟检查中先验证、后发布的顺序是流程的核心。变更日志格式CHANGELOG 条目由脚本自动生成并附带 PR 链接与作者若 PR 标题包含额外 issue 编号脚本也会按既定逻辑处理参见 print-changelog-update.sh 的 sed/grep 处理。当前仓库版本参考仓库 package.json 中记录的版本为1.25.0CHANGELOG.md 最新条目亦为1.25.02025-12-03可作为验证发布流程时对照的基准版本。赞分享开发工具前端【免费下载链接】speedscope A fast, interactive web-based viewer for performance profiles.项目地址https://gitcode.com/gh_mirrors/sp/speedscope点击查看免费下载相关推荐Mastra 稳定版发布冒烟测试全流程指南从 npm 发布确认到最终签署验证Mastra 稳定版发布冒烟测试全流程指南从 npm 发布确认到最终签署验证 导读 本文讲解 Mastra 开源仓库中面向 稳定版stable/full r人工智能Agent 框架AI AgentRAG后端Mastra 冒烟测试完全指南本地验证、云部署与 Release 发布前检查实战Mastra 冒烟测试完全指南本地验证、云部署与 Release 发布前检查实战 本文基于 Mastra 仓库中 .claude/skills/mastra人工智能Agent 框架AI AgentRAG后端NES.css发布管理npm包发布流程NES.css发布管理npm包发布流程 你是否正在为开源项目的npm包发布流程感到困惑本文将以NES.css项目为例详细介绍从代码准备到最终发布到npm仓前端UI组件创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/15 18:55:15 · 阅读 1.2k speedscope 发布管理员指南：发布前冒烟测试、npm 发布与网站部署全流程
开发工具前端【免费下载链接】speedscope A fast, interactive web-based viewer for performance profiles.项目地址https://gitcode.com/gh_mirrors/sp/speedscope点击查看免费下载本文面向 speedscope 仓库的管理员与维护者完整梳理从发布前测试到创建并发布新版本再到验证发布结果的整套运维流程包括 mock 安装测试脚本的原理、自动化发布脚本publish-and-deploy.sh的七步执行链路、CLI 验证要点以及网站gh-pages部署的底层机制。读完本文你将能够独立完成一次 speedscope 版本的发布、回滚前的验证与发布后的核验。文档定位这份管理员指南覆盖什么README-ADMINS.md 是仓库中专门面向管理员admin的过程文档与面向普通用户的 README.md 职责不同后者讲解如何导入 profile、如何使用视图与快捷键前者聚焦如何安全地把一个新版本发布出去。文档首先声明了一个重要前提发布流程假定在 macOS 上运行。原文明确写到在 Linux 上probably works可能可用而在 Windows 上almost definitely does not work几乎肯定不可用。这意味着管理员在非 macOS 环境执行发布前应优先在 macOS 机器或等效的 Unix 环境中进行尤其是下文会提到的npm pack、tar解包、临时目录路径等步骤与 Unix 工具链强相关。整个发布流程由一组位于 scripts 目录的 bash 脚本支撑它们是本文所有命令的底层实现脚本职责prepare-test-installation.sh模拟一次 npm 发布并安装用于发布前冒烟测试publish-and-deploy.sh一键执行版本号提升、变更日志、git 提交打标签、npm 发布、网站部署、zip 构建deploy.sh将构建产物推送到 gh-pages 分支完成网站部署prepare-zip-file.sh基于 npm 包内容生成可独立使用的 zip 版本print-changelog-update.sh根据最近一次 tag 的 git 提交记录生成变更日志片段prepack.sh构建 release 产物--protocol http或fileci.shCI 阶段执行的类型检查、lint、测试覆盖率检查第一步发布前测试Test the releasespeedscope 的所有自动化测试都由 CI 承担详见下文与 CI 的衔接一节因此发布前只需要做少量冒烟检查sanity checks确认构建与发布相关的机器链路本身工作正常。运行模拟安装脚本在仓库根目录执行scripts/prepare-test-installation.sh该命令会做一次mock 发布与安装mock publish installation以确认即将发布的版本确实可用。命令结束时终端会打印一条cd指令提示切换到测试安装目录输出形如Run the following command to switch into the test directory cd /var/folders/l0/qtd9z14973s2tw81vmzwkyp00000gp/T/speedscope-test-installation.9Ssdd2PZ/package具体路径由mktemp动态生成每次运行都不同。脚本背后mock publish 的完整链路从 prepare-test-installation.sh 的源码可以看到这个模拟发布到底做了什么set -euxo pipefail TESTDIRmktemp -d -t speedscope-test-installation # 1. 创建临时目录 PACKEDNAMEnpm pack | tail -n1 # 2. 本地打包生成 .tgz mv $PACKEDNAME $TESTDIR # 3. 把包移入临时目录 cd $TESTDIR tar -xvvf $PACKEDNAME # 4. 解包 cd package npm install # 5. 安装依赖 set x echo echo Run the following command to switch into the test directory echo cd $TESTDIR/package关键点在于脚本用npm pack本地打包替代了npm publish真实发布到 npm registry再用tar解包、npm install复刻了用户通过npm install -g speedscope会经历的安装过程。这样可以在不污染 npm registry 的前提下完整验证打包 → 安装 → 运行链路。set -euxo pipefail保证任何一步失败都会立即中断避免带病发布。该脚本依赖 package.json 中的files字段约定——只有bin/cli.mjs、dist/release/**排除*.map会被打进包这也决定了冒烟测试能验证的范围。手工冒烟检查步骤执行上面打印的cd命令进入测试目录后按文档要求做两项检查运行 CLI 并导入本地文件执行bin/cli.mjs浏览器会打开一份 speedscope 副本。点击页面上的 browse 按钮从磁盘导入一个 profile 文件确认导入功能正常。测试命令行参数直接加载执行bin/cli.mjs dist/release/perf-vertx*此时浏览器应立即打开 speedscope并且 perf-vertx 文件立即加载完成无需再手动导入。关于第二个检查项中的dist/release/perf-vertx*通配符从源码看speedscope 内置了一份名为perf-vertx-stacks-01-collapsed-all.txt的示例 profile位于 sample/profiles/stackcollapse/perf-vertx-stacks-01-collapsed-all.txt并且在应用入口 src/views/application.tsx 中通过loadExample直接fetch该文件作为演示数据。构建产物目录dist/release/中会包含对应的发布版示例文件因此这条命令既能验证 CLI 的参数加载路径也能顺带验证示例数据在发布包中是否完整。CLI 加载机制的源码佐证CLI 本体是 bin/cli.mjs它在package.json中被声明为bin入口。当传入文件路径时它会把文件内容转为 base64写入一个临时.js文件再以#localProfilePathjs 路径的 hash 参数打开dist/release/index.html浏览器端在 src/views/application.tsx 中读取hashParams.localProfilePath加载该临时脚本并调用loadFileFromBase64(filename, base64source)完成导入hash 参数解析逻辑见 src/lib/hash-params.ts并有对应测试 src/lib/hash-params.test.ts 覆盖#localProfilePath...的解析。此外 CLI 还支持以-作为路径参数从 stdin 读取cat /path/to/profile | speedscope -以及--help/-h、--version/-v两个标志。由于 macOS 的open与 Windows 的start会忽略 URL 中的 hash 参数CLI 在darwin/win32平台还会额外生成一个临时 HTML 重定向页来绕开该问题——这也再次印证了发布流程假定 macOS的文档前提。第二步创建并发布新版本Create publish the new release发布前置条件执行发布前需要确认以下三项就绪安装并认证 GitHub CLI运行gh auth status确认已登录。npm 身份可用运行npm whoami确认 npm 账号可用。浏览器登录 npm在默认浏览器中确保已登录 npm 账号——文档特别提醒若未登录在 npm publish 过程中打开 authenticate 链接时会看到 404 页面该提醒来自 CHANGELOG 中 1.18.0 的 #457 变更专门为 npm 登录指引补充。执行发布脚本确认就绪后运行scripts/publish-and-deploy.sh脚本接受一个必填参数用于指定版本号的提升方式。从 publish-and-deploy.sh 源码看参数取值可以是minor、patch或直接指定完整版本号Usage: $0 minor | patch | version e.g. $0 patch七步执行链路拆解从脚本源码scripts/publish-and-deploy.sh可以看到一次发布实际上是如下 7 个环节的串联类型检查node_modules/.bin/tsc --noEmit与npm run typecheck等价单元测试npm run jest实际由 test-setup.sh 先解压测试用 zip 样本再运行 Jest提升版本号但不提交npm version $version_arg --no-git-tag-version --no-commit-hooks同时更新package.json与package-lock.json但不立即创建 commit 或 tag更新变更日志调用 print-changelog-update.sh 生成自上一个 tag 以来的提交记录摘要格式与 CHANGELOG.md 保持一致## [版本号] - 日期带 PR 编号与作者署名并前置写入 CHANGELOG.md提交并打标签git add CHANGELOG.md package.json package-lock.json以版本号为 commit message创建v$version形式的 tag然后git push与git push --tags发布到 npmnpm publish部署网站 构建独立 zipnpm run deploy对应 deploy.sh再调用 prepare-zip-file.sh 生成dist/release/speedscope-$version.zip。收尾在 GitHub 创建 Release脚本执行完毕后并不会自动创建 GitHub Release而是打印出人工操作指引包括需要访问的 GitHub Releases 新建页面tag: v$versiontitle: v$versionattachment: dist/release/speedscope-$version.zip以及本次生成的变更日志内容。脚本源码中注释说明这一环节几乎但并非完全可以用gh release create自动化脚本里甚至保留了可参考的命令样例之所以保留人工步骤是因为两个未解决的问题——--attach标志的退出行为不理想且不希望 Release 注释包含 CHANGELOG 中的版本号与日期。因此在当前版本中管理员仍需在网页上手工创建 Release 并上传 zip。发布时自动执行的构建脚本第 7 步的 zip 构建依赖 prepare-zip-file.sh它从 npm registry 拉取刚发布的包npm pack speedscope解包后把dist/release/**拷贝进speedscope/目录附带 LICENSE 与一个说明index.html用途的 README最后打包为speedscope-version.zip放到dist/release/。发布构建本身由 prepack.sh 完成对应npm run prepack使用--protocol file生成可直接双击打开的独立版本而 deploy.sh 走的是./scripts/prepack.sh --outdir $OUTDIR --protocol http即面向 HTTP 服务的版本。prepack.sh还会在产物目录写入release.txt记录 npm 包名、构建日期与git rev-parse HEAD以及file-format-schema.json由 generate-file-format-schema-json.js 生成便于事后定位具体构建对应的 commit。第三步验证发布结果Verifying the release验证 npm 包可用发布完成后从最终用户视角验证 npm 包npm install -g speedscope随后验证两种调用方式无参数启动直接运行speedscope浏览器应打开 speedscope 界面带参数直接加载 profile运行speedscope sample/profiles/stackcollapse/simple.txt浏览器应立即打开并加载该 profile。仓库中的 sample/profiles/stackcollapse/simple.txt 是标准的 stackcollapse 格式文本每行一个;分隔的调用栈加权重数值例如a;b;c 1 a;b;c 1 a;b;d 4 a;b;c 3 a;b 5正是验证 CLI 加载链路的最小样例。此验证与发布前测试中的bin/cli.mjs dist/release/perf-vertx*形成闭环前者验证源码包后者验证 npm 安装后的全局命令。验证网站部署完成npm 发布成功只代表包可用网站部署是独立的一条链路。打开 https://www.speedscope.app/ 后查看浏览器控制台中显示的版本号确认其与本次发布的版本一致即表示 gh-pages 部署完成。网站部署的机制见 deploy.sh脚本先以--protocol http构建产物到dist/http-release再对仓库做一次--depth 1的浅克隆切到gh-pages分支把构建产物拷贝进去、写入www.speedscope.app的 CNAME 记录随后在本地http.server 4444启动服务器供人工验证按CtrlC后确认输入yes才git push origin HEAD:gh-pages完成部署。这也解释了为什么验证时要以控制台版本号为准——部署内容来自本次构建产物。与 CI 的衔接发布前的自动化测试保障来自 CI。仓库的 scripts/ci.sh对应npm test依次执行npm run typecheck npm run lint npm run coverage node scripts/generate-file-format-schema-json.js /dev/null即类型检查tsc --noEmit、ESLint、带覆盖率统计的 Jest 测试以及文件格式 schema 的生成校验。其中 jest 配置package.json使用 jsdom 环境、ts-jest/esbuild-jest转译并会把 Java Flight Recorder 的 wasm 模块 mock 掉jfrview_bg.wasm→ src/import/java-flight-record.mock.ts。发布脚本内部复用了其中tsc与jest两步相当于发布前再跑一遍关键检查的双保险。关键脚本速查阶段命令/脚本产出发布前测试scripts/prepare-test-installation.sh临时目录中的可运行安装包发布scripts/publish-and-deploy.sh patch\|minor\|version新 tag、npm 包、gh-pages 部署、dist/release/speedscope-v.zip变更日志scripts/print-changelog-update.sh version可前置到 CHANGELOG.md 的更新片段网站部署npm run deploydeploy.shgh-pages 分支更新zip 构建scripts/prepare-zip-file.shdist/release/speedscope-v.zipCInpm testci.sh类型检查、lint、覆盖率、schema 生成注意事项与常见问题平台限制整套流程假定 macOSLinux 可能可用、Windows 几乎不可用。CLI 在 Windows 上需要wait: true打开浏览器见 bin/cli.mjs且 macOS/Windows 均需要临时 HTML 重定向来携带 hash 参数这些平台差异是假定 macOS的主要原因之一。版本参数发布脚本只接受patch、minor或完整版本号三种参数传入其他值会直接报错退出。顺序不可颠倒必须先通过发布前测试与手工冒烟检查再执行发布脚本npm publish一旦执行即不可撤回所以冒烟检查中先验证、后发布的顺序是流程的核心。变更日志格式CHANGELOG 条目由脚本自动生成并附带 PR 链接与作者若 PR 标题包含额外 issue 编号脚本也会按既定逻辑处理参见 print-changelog-update.sh 的 sed/grep 处理。当前仓库版本参考仓库 package.json 中记录的版本为1.25.0CHANGELOG.md 最新条目亦为1.25.02025-12-03可作为验证发布流程时对照的基准版本。赞分享开发工具前端【免费下载链接】speedscope A fast, interactive web-based viewer for performance profiles.项目地址https://gitcode.com/gh_mirrors/sp/speedscope点击查看免费下载相关推荐Mastra 稳定版发布冒烟测试全流程指南从 npm 发布确认到最终签署验证Mastra 稳定版发布冒烟测试全流程指南从 npm 发布确认到最终签署验证 导读 本文讲解 Mastra 开源仓库中面向 稳定版stable/full r人工智能Agent 框架AI AgentRAG后端Mastra 冒烟测试完全指南本地验证、云部署与 Release 发布前检查实战Mastra 冒烟测试完全指南本地验证、云部署与 Release 发布前检查实战 本文基于 Mastra 仓库中 .claude/skills/mastra人工智能Agent 框架AI AgentRAG后端NES.css发布管理npm包发布流程NES.css发布管理npm包发布流程 你是否正在为开源项目的npm包发布流程感到困惑本文将以NES.css项目为例详细介绍从代码准备到最终发布到npm仓前端UI组件创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考