前端【免费下载链接】beakerAn experimental peer-to-peer Web browser项目地址https://gitcode.com/gh_mirrors/be/beaker点击查看免费下载导读scripts/how-to-make-a-release.md 是 Beaker 项目维护者整理的发版操作手册记录了从依赖安装、构建、补丁应用到最终签名打包的完整步骤。本文将这份手册作为主体骨架结合仓库中scripts/目录下的构建脚本与打包配置逐条展开讲解每个命令背后实际执行的逻辑并给出 macOS 与 Windows 两个平台签名发布所需的完整环境变量配置帮助你在接手 Beaker或同类 Electron 应用发布任务时能照着步骤一次跑通。适用前提以下所有命令、补丁与配置均以当前仓库快照为准涉及 Electron 11.0.0-beta.18、electron-builder 22.x 及应用版本 1.1.0见 app/package.json。一、发版流程总览整条发布链路可以概括为六个步骤校验依赖安装——保证根目录与app/bg/dat/converter的node_modules都完整同步版本与发布说明——更新桌面应用版本号与 release-notes 链接构建——npm run build用 rollup browserify 产出*.build.js打补丁——手动修补 electron-builder 的AppFileWalker.js防止打包器误删dat相关node_modules打包——npm run release调用 electron-builder 生成各平台安装包注入签名凭据——按平台提供 Apple IDmacOS 公证或代码签名证书Windows。文档作者在开头自嘲“The process is currently a little silly. This file is getting progressively less awful.”意思是该流程仍高度依赖手工步骤本文将把这些“手工”步骤逐一定位到源码讲清楚为什么需要它们。二、第一步检查依赖安装手册要求先执行npm install并特别确认app/bg/dat/converter目录下有自己的node_modules。这个要求不是多余的原因在于仓库的安装脚本做了特殊设计。查看 scripts/package.jsonpostinstall: cd ../app npm install cd bg/dat/converter npm installnpm install触发postinstall钩子后会依次执行三段安装先安装app/Electron 应用主体的依赖再进入app/bg/dat/converter安装它自己的依赖。app/bg/dat/converter是一个独立的小包其 package.json 只声明了一个依赖{ dependencies: { beaker/dat-legacy-tools: ^1.1.0 } }而这个模块的功能很简单app/bg/dat/converter/index.js 只有一行require(beaker/dat-legacy-tools/bin.js)它负责把旧dat://协议的本地存储数据迁移到新的hyper://驱动上。由于它是独立目录、独立依赖树如果它的node_modules缺失打包出来的安装包内将缺少这个转换器用户升级后旧数据就无法迁移。因此发版前检查这一处依赖安装是整个流程的第一个硬性门槛。三、第二步同步桌面版本与 release-notes 链接手册用极其强烈的措辞“SO HELP ME GOD if you forget this Ill kill you.”强调这一步不能漏发布前必须更新桌面版本号以及 release-notes 链接。对应到仓库里桌面版本号维护在两个位置app/package.json 的version: 1.1.0这是应用实际版本也是打包产物文件名的一部分scripts/package.json 的 devDependencies 锁定了 Electron 版本11.0.0-beta.18。同时需要确认 scripts/afterSignHook.js 中的appIdcom.bluelinklabs.beaker-browser与 scripts/package.json 的appId保持一致否则公证签名会因 bundle id 不匹配而失败。release-notes 链接指的是自动更新auto-updater在通知用户“有新版本”时展示的更新说明地址发布时同样需要同步指向新版本对应的页面。这一步属于流程纪律问题版本号不一致会导致安装包文件命名、自动更新比对、公证 bundle id 等多处错位所以被列为发版前必须核对的事项。四、第三步构建npm run build手册中的构建命令是npm run build在 scripts/package.json 中它映射到gulp build而 scripts/gulpfile.js 加载了./tasks/build/build、start、rebuild、postbuild四个任务文件其中build任务定义在 scripts/tasks/build/build.jsgulp.task(build, gulp.series([bundle]));bundle任务本身又由两步组成build.jsgulp.task(bundle, gulp.series([burnthemall-maybe], bundleTask));4.1 Electron 版本变更检测burnthemall-maybe构建前会先执行burnthemall-maybe检查build.js读取scripts/package.json中声明的 electron 版本与scripts/node_modules/electron/package.json里实际安装的版本比对不一致时自动触发npm run burnthemall做一次完整的重装重建并中止本次构建。这是为了避免原生模块与 Electron 版本不匹配导致运行时崩溃。4.2 bundle 任务rollup browserifybundleTaskbuild.js会并行打包一批入口文件覆盖主进程与各前台界面app/main.js→app/main.build.js主进程入口也即 app/package.json 的main: main.build.jsfg/webview-preload/index.js、fg/shell-window/index.js、fg/shell-menus/index.js、fg/location-bar/index.js、fg/prompts/index.js、fg/perm-prompt/index.js、fg/modals/index.js、fg/json-renderer/index.jsuserland/site-info/js/main.js、userland/editor/js/main.js、userland/settings/js/main.js等前端模块。打包方式见 scripts/tasks/build/bundle.js先用rollup以 CJS 格式做模块合并并把 Node 内置模块、electron以及app/package.json中声明的依赖统一视为external不参与打包对前台模块再额外走一遍browserify以basedir指向app/目录、builtins按需启用并通过excludeNodeModules/browserifyExclude排除fs等模块确保前台代码能安全运行在受限的 webview 环境里。构建产物会直接以*.build.js的形式写回app/目录因此后续打包阶段会把这些产物打进安装包。五、第四步手动修补 electron-builder 的 AppFileWalker.js这是整个流程中最“hack”的一步。手册要求对scripts/node_modules下的app-builder-lib/out/util/AppFileWalker.js手动应用补丁if (!nodeModulesFilter(file, fileStat)) { if (!file.includes(dat)) { return false; } } if (file.endsWith(nodeModulesSystemDependentSuffix)) { if (!file.includes(dat)) { return false; } }5.1 为什么要打这个补丁electron-builder 在打包时会用nodeModulesFilter过滤掉不需要打进安装包的node_modules文件例如只用于构建期的包。但 Beaker 里有两个包含dat关键字的依赖需要强制保留在安装包内app/bg/dat/converter/node_modules/beaker/dat-legacy-tools旧 dat 数据迁移工具scripts/package.jsonasarUnpack中列出的./node_modules/beaker/dat-legacy-tools/**。补丁的逻辑是当nodeModulesFilter判定某个文件“不属于需要打包的 node_modules”时追加一次兜底判断——只要文件路径里包含dat就放行而不是直接拒绝。这样 electron-builder 就不会把dat相关的运行时依赖从./app/bg/dat/converter/node_modules里删掉。5.2 补丁的注意点补丁位置是scripts/node_modules构建工具链自己的依赖重新执行npm install或升级 electron-builder 都会把补丁覆盖掉所以它是发版流程的固定动作不能只打一次路径匹配用的是file.includes(dat)这种宽松匹配凡路径中带dat的都会被保留范围比精确匹配大属于“宁多勿缺”的策略。六、第五步打包发布npm run release依赖、版本、构建、补丁都就绪后执行npm run release该命令在 scripts/package.json 中的定义为release: electron-builder -p never gulp postbuild它由两段组成6.1 electron-builder -p never-p never表示打包但不自动发布publish 配置为never产物统一输出到dist/目录。electron-builder 会读取 scripts/package.json 中的build配置段directoriesapp指向../appbuildResources指向../buildoutput指向../distasar: false应用以未打包为 asar 的目录形式分发配合asarUnpack中的sodium-native、hyperdrive-daemon等原生模块需求protocols注册http、https、hyper、dat四个 URL scheme让 Beaker 成为这些协议的默认处理程序对应 Linux 桌面配置里的x-scheme-handler/*MimeTypemachardenedRuntime: true、entitlements指向../build/entitlements.plist并声明了摄像头/麦克风的用途描述appImage配置 Linux AppImage 的桌面条目与 MimeType。6.2 gulp postbuild产物重命名打包完成后postbuild任务scripts/tasks/postbuild.js会对dist/中的产物做一次重命名Windows 安装包Beaker Browser Setup-{version}.exe→beaker-browser-setup-{version}.exemacOSBeaker Browser-{version}.dmg与Beaker Browser-{version}-mac.zip→beaker-browser{version}.dmg/beaker-browser{version}-mac.zip。重命名的原因注释写得很直白electron-builder 默认输出Beaker Browser-{version}{ext}这种带空格与大写的文件名而electron-updater期望的文件名是beaker-browser-{version}{ext}配置层面一时改不过来于是用 gulp 任务在产物落地后统一改名保证自动更新比对能命中。七、第六步按平台注入签名凭据手册强调macOS 与 Windows 各有必须提供的环境变量缺失将导致签名/公证失败。7.1 macOSApple ID 公证appleIdpfrazeegmail.com appleIdPassword{be paul to have this}两个变量的真实消费方是 scripts/afterSignHook.js它通过 scripts/package.json 的afterSign: ./afterSignHook.js挂接到 electron-builder 签名完成之后await electron_notarize.notarize({ appBundleId: appId, appPath: appPath, appleId: process.env.appleId, appleIdPassword: process.env.appleIdPassword, });结合 afterSignHook.js 的整体逻辑可以还原完整行为钩子只在process.platform darwin时执行其他平台直接返回appId硬编码为com.bluelinklabs.beaker-browser与 scripts/package.json 保持一致应用路径由params.appOutDir与productFilename拼出即输出目录/Beaker Browser.app然后调用electron-notarize的notarize()把appleId、appleIdPassword直接传给 Apple 公证服务。appleIdPassword手册中写的是占位符{be paul to have this}意思是这个值需要向维护者Paul索取不要在仓库里明文保存。实际上它应当填写 Apple ID 的 App 专用密码app-specific password而不是登录密码本身。7.2 Windows代码签名证书WindowsPowerShell需要$env:CSC_LINK \path\to\.pfx $env:CSC_KEY_PASSWORD {be paul to have this}CSC_LINK指向代码签名证书文件.pfx的路径CSC_KEY_PASSWORD该证书的私钥密码。这两个变量是 electron-builder 在 Windows 平台做 Authenticode 签名时的标准凭据签名缺失时 Windows 会弹出 SmartScreen 警告。同样地证书密码也以“向维护者索取”的方式流转不进入仓库。7.3 Linux 平台说明手册没有为 Linux 列出专门的凭据要求。结合构建配置Linux 走 AppImage 形态分发scripts/package.json不涉及 Apple 公证与 Authenticode 签名因此无需注入上述环境变量即可完成npm run release。八、原生模块的特殊处理npm run rebuild如果你的开发机需要从源码重新编译原生模块比如切换了 Node/Electron 版本之后仓库还提供了一个rebuild任务scripts/tasks/rebuild.js。它针对sqlite3等原生模块执行npm rebuild sqlite3 --runtimeelectron --target11.0.0-beta.18 \ --disturlhttps://electronjs.org/headers --build-from-source其中--target11.0.0-beta.18必须与 scripts/package.json 中的 Electron 版本一致macOS 上还会额外注入CXXFLAGS/LDFLAGS-mmacosx-version-min10.10以保证兼容旧系统。这一步与发布流程的“Electron 版本变更检测burnthemall”是配套的一旦版本变更需要先重建原生模块再走 build → 补丁 → release 的主链路。九、发版自检清单结合手册与仓库实现一次完整发版建议按如下清单核对步骤动作对应仓库证据1npm install确认app/bg/dat/converter/node_modules存在scripts/package.json、app/bg/dat/converter/index.js2更新app/package.json的version与 release-notes 链接app/package.json3npm run buildscripts/tasks/build/build.js4手工修补scripts/node_modules/app-builder-lib/out/util/AppFileWalker.js补丁见 how-to-make-a-release.md5npm run releasemacOS/Windows 需先注入签名环境变量scripts/package.json、scripts/afterSignHook.js6检查dist/产物文件名是否已重命名为beaker-browser-*scripts/tasks/postbuild.js十、常见问题与注意事项补丁被覆盖scripts/node_modules内的AppFileWalker.js补丁在每次重新安装依赖后都会消失发布前必须重新检查、重新应用。公证失败确认afterSignHook.js中的appId与 electron-builder 配置一致且appleIdPassword使用的是 App 专用密码。自动更新比对不到新版本检查dist/产物是否已被postbuild重命名为beaker-browser-{version}...electron-updater 只认小写、无空格的文件名。converter 丢失安装包内若缺少app/bg/dat/converter/node_modules多半是补丁未应用或未检查依赖安装旧dat://数据将无法在升级后迁移。手册结尾那句轻松的“Its just that easy. Boy how about that.”背后正是上述这些容易被忽略的手工环节。对照本指南逐项执行即可把 Beaker 的发布流程稳定复现。赞分享前端【免费下载链接】beakerAn experimental peer-to-peer Web browser项目地址https://gitcode.com/gh_mirrors/be/beaker点击查看免费下载相关推荐Presenton macOS 签名 DMG 构建全流程Developer ID 签名、公证、装订与发布校验实战指南Presenton macOS 签名 DMG 构建全流程Developer ID 签名、公证、装订与发布校验实战指南 本文是 Presenton开源 AIAI 应用人工智能大模型后端前端桌面应用MCP 服务AI AgentRAG本地部署企业应用终极Windows数字许可证激活方案CMWTAT_Digital_Edition让系统激活如此简单终极Windows数字许可证激活方案CMWTAT_Digital_Edition让系统激活如此简单 在Windows系统使用过程中激活问题一直是许多用户面临桌面应用操作系统ILSpy macOS 发布全流程CI 无签名构建、离线签名公证与 DMG 打包实战ILSpy macOS 发布全流程CI 无签名构建、离线签名公证与 DMG 打包实战 本篇指南以 ILSpy 仓库中 BuildTools/packaging逆向工程开发工具桌面应用上一篇Context Hub 内容仓库完全解析Markdown Frontmatter 组织数千篇 API 文档下一篇SOEM轻量级开源EtherCAT主站解决方案完全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Beaker 浏览器发版全流程指南：从依赖校验、构建打包到 macOS/Windows 签名发布
前端【免费下载链接】beakerAn experimental peer-to-peer Web browser项目地址https://gitcode.com/gh_mirrors/be/beaker点击查看免费下载导读scripts/how-to-make-a-release.md 是 Beaker 项目维护者整理的发版操作手册记录了从依赖安装、构建、补丁应用到最终签名打包的完整步骤。本文将这份手册作为主体骨架结合仓库中scripts/目录下的构建脚本与打包配置逐条展开讲解每个命令背后实际执行的逻辑并给出 macOS 与 Windows 两个平台签名发布所需的完整环境变量配置帮助你在接手 Beaker或同类 Electron 应用发布任务时能照着步骤一次跑通。适用前提以下所有命令、补丁与配置均以当前仓库快照为准涉及 Electron 11.0.0-beta.18、electron-builder 22.x 及应用版本 1.1.0见 app/package.json。一、发版流程总览整条发布链路可以概括为六个步骤校验依赖安装——保证根目录与app/bg/dat/converter的node_modules都完整同步版本与发布说明——更新桌面应用版本号与 release-notes 链接构建——npm run build用 rollup browserify 产出*.build.js打补丁——手动修补 electron-builder 的AppFileWalker.js防止打包器误删dat相关node_modules打包——npm run release调用 electron-builder 生成各平台安装包注入签名凭据——按平台提供 Apple IDmacOS 公证或代码签名证书Windows。文档作者在开头自嘲“The process is currently a little silly. This file is getting progressively less awful.”意思是该流程仍高度依赖手工步骤本文将把这些“手工”步骤逐一定位到源码讲清楚为什么需要它们。二、第一步检查依赖安装手册要求先执行npm install并特别确认app/bg/dat/converter目录下有自己的node_modules。这个要求不是多余的原因在于仓库的安装脚本做了特殊设计。查看 scripts/package.jsonpostinstall: cd ../app npm install cd bg/dat/converter npm installnpm install触发postinstall钩子后会依次执行三段安装先安装app/Electron 应用主体的依赖再进入app/bg/dat/converter安装它自己的依赖。app/bg/dat/converter是一个独立的小包其 package.json 只声明了一个依赖{ dependencies: { beaker/dat-legacy-tools: ^1.1.0 } }而这个模块的功能很简单app/bg/dat/converter/index.js 只有一行require(beaker/dat-legacy-tools/bin.js)它负责把旧dat://协议的本地存储数据迁移到新的hyper://驱动上。由于它是独立目录、独立依赖树如果它的node_modules缺失打包出来的安装包内将缺少这个转换器用户升级后旧数据就无法迁移。因此发版前检查这一处依赖安装是整个流程的第一个硬性门槛。三、第二步同步桌面版本与 release-notes 链接手册用极其强烈的措辞“SO HELP ME GOD if you forget this Ill kill you.”强调这一步不能漏发布前必须更新桌面版本号以及 release-notes 链接。对应到仓库里桌面版本号维护在两个位置app/package.json 的version: 1.1.0这是应用实际版本也是打包产物文件名的一部分scripts/package.json 的 devDependencies 锁定了 Electron 版本11.0.0-beta.18。同时需要确认 scripts/afterSignHook.js 中的appIdcom.bluelinklabs.beaker-browser与 scripts/package.json 的appId保持一致否则公证签名会因 bundle id 不匹配而失败。release-notes 链接指的是自动更新auto-updater在通知用户“有新版本”时展示的更新说明地址发布时同样需要同步指向新版本对应的页面。这一步属于流程纪律问题版本号不一致会导致安装包文件命名、自动更新比对、公证 bundle id 等多处错位所以被列为发版前必须核对的事项。四、第三步构建npm run build手册中的构建命令是npm run build在 scripts/package.json 中它映射到gulp build而 scripts/gulpfile.js 加载了./tasks/build/build、start、rebuild、postbuild四个任务文件其中build任务定义在 scripts/tasks/build/build.jsgulp.task(build, gulp.series([bundle]));bundle任务本身又由两步组成build.jsgulp.task(bundle, gulp.series([burnthemall-maybe], bundleTask));4.1 Electron 版本变更检测burnthemall-maybe构建前会先执行burnthemall-maybe检查build.js读取scripts/package.json中声明的 electron 版本与scripts/node_modules/electron/package.json里实际安装的版本比对不一致时自动触发npm run burnthemall做一次完整的重装重建并中止本次构建。这是为了避免原生模块与 Electron 版本不匹配导致运行时崩溃。4.2 bundle 任务rollup browserifybundleTaskbuild.js会并行打包一批入口文件覆盖主进程与各前台界面app/main.js→app/main.build.js主进程入口也即 app/package.json 的main: main.build.jsfg/webview-preload/index.js、fg/shell-window/index.js、fg/shell-menus/index.js、fg/location-bar/index.js、fg/prompts/index.js、fg/perm-prompt/index.js、fg/modals/index.js、fg/json-renderer/index.jsuserland/site-info/js/main.js、userland/editor/js/main.js、userland/settings/js/main.js等前端模块。打包方式见 scripts/tasks/build/bundle.js先用rollup以 CJS 格式做模块合并并把 Node 内置模块、electron以及app/package.json中声明的依赖统一视为external不参与打包对前台模块再额外走一遍browserify以basedir指向app/目录、builtins按需启用并通过excludeNodeModules/browserifyExclude排除fs等模块确保前台代码能安全运行在受限的 webview 环境里。构建产物会直接以*.build.js的形式写回app/目录因此后续打包阶段会把这些产物打进安装包。五、第四步手动修补 electron-builder 的 AppFileWalker.js这是整个流程中最“hack”的一步。手册要求对scripts/node_modules下的app-builder-lib/out/util/AppFileWalker.js手动应用补丁if (!nodeModulesFilter(file, fileStat)) { if (!file.includes(dat)) { return false; } } if (file.endsWith(nodeModulesSystemDependentSuffix)) { if (!file.includes(dat)) { return false; } }5.1 为什么要打这个补丁electron-builder 在打包时会用nodeModulesFilter过滤掉不需要打进安装包的node_modules文件例如只用于构建期的包。但 Beaker 里有两个包含dat关键字的依赖需要强制保留在安装包内app/bg/dat/converter/node_modules/beaker/dat-legacy-tools旧 dat 数据迁移工具scripts/package.jsonasarUnpack中列出的./node_modules/beaker/dat-legacy-tools/**。补丁的逻辑是当nodeModulesFilter判定某个文件“不属于需要打包的 node_modules”时追加一次兜底判断——只要文件路径里包含dat就放行而不是直接拒绝。这样 electron-builder 就不会把dat相关的运行时依赖从./app/bg/dat/converter/node_modules里删掉。5.2 补丁的注意点补丁位置是scripts/node_modules构建工具链自己的依赖重新执行npm install或升级 electron-builder 都会把补丁覆盖掉所以它是发版流程的固定动作不能只打一次路径匹配用的是file.includes(dat)这种宽松匹配凡路径中带dat的都会被保留范围比精确匹配大属于“宁多勿缺”的策略。六、第五步打包发布npm run release依赖、版本、构建、补丁都就绪后执行npm run release该命令在 scripts/package.json 中的定义为release: electron-builder -p never gulp postbuild它由两段组成6.1 electron-builder -p never-p never表示打包但不自动发布publish 配置为never产物统一输出到dist/目录。electron-builder 会读取 scripts/package.json 中的build配置段directoriesapp指向../appbuildResources指向../buildoutput指向../distasar: false应用以未打包为 asar 的目录形式分发配合asarUnpack中的sodium-native、hyperdrive-daemon等原生模块需求protocols注册http、https、hyper、dat四个 URL scheme让 Beaker 成为这些协议的默认处理程序对应 Linux 桌面配置里的x-scheme-handler/*MimeTypemachardenedRuntime: true、entitlements指向../build/entitlements.plist并声明了摄像头/麦克风的用途描述appImage配置 Linux AppImage 的桌面条目与 MimeType。6.2 gulp postbuild产物重命名打包完成后postbuild任务scripts/tasks/postbuild.js会对dist/中的产物做一次重命名Windows 安装包Beaker Browser Setup-{version}.exe→beaker-browser-setup-{version}.exemacOSBeaker Browser-{version}.dmg与Beaker Browser-{version}-mac.zip→beaker-browser{version}.dmg/beaker-browser{version}-mac.zip。重命名的原因注释写得很直白electron-builder 默认输出Beaker Browser-{version}{ext}这种带空格与大写的文件名而electron-updater期望的文件名是beaker-browser-{version}{ext}配置层面一时改不过来于是用 gulp 任务在产物落地后统一改名保证自动更新比对能命中。七、第六步按平台注入签名凭据手册强调macOS 与 Windows 各有必须提供的环境变量缺失将导致签名/公证失败。7.1 macOSApple ID 公证appleIdpfrazeegmail.com appleIdPassword{be paul to have this}两个变量的真实消费方是 scripts/afterSignHook.js它通过 scripts/package.json 的afterSign: ./afterSignHook.js挂接到 electron-builder 签名完成之后await electron_notarize.notarize({ appBundleId: appId, appPath: appPath, appleId: process.env.appleId, appleIdPassword: process.env.appleIdPassword, });结合 afterSignHook.js 的整体逻辑可以还原完整行为钩子只在process.platform darwin时执行其他平台直接返回appId硬编码为com.bluelinklabs.beaker-browser与 scripts/package.json 保持一致应用路径由params.appOutDir与productFilename拼出即输出目录/Beaker Browser.app然后调用electron-notarize的notarize()把appleId、appleIdPassword直接传给 Apple 公证服务。appleIdPassword手册中写的是占位符{be paul to have this}意思是这个值需要向维护者Paul索取不要在仓库里明文保存。实际上它应当填写 Apple ID 的 App 专用密码app-specific password而不是登录密码本身。7.2 Windows代码签名证书WindowsPowerShell需要$env:CSC_LINK \path\to\.pfx $env:CSC_KEY_PASSWORD {be paul to have this}CSC_LINK指向代码签名证书文件.pfx的路径CSC_KEY_PASSWORD该证书的私钥密码。这两个变量是 electron-builder 在 Windows 平台做 Authenticode 签名时的标准凭据签名缺失时 Windows 会弹出 SmartScreen 警告。同样地证书密码也以“向维护者索取”的方式流转不进入仓库。7.3 Linux 平台说明手册没有为 Linux 列出专门的凭据要求。结合构建配置Linux 走 AppImage 形态分发scripts/package.json不涉及 Apple 公证与 Authenticode 签名因此无需注入上述环境变量即可完成npm run release。八、原生模块的特殊处理npm run rebuild如果你的开发机需要从源码重新编译原生模块比如切换了 Node/Electron 版本之后仓库还提供了一个rebuild任务scripts/tasks/rebuild.js。它针对sqlite3等原生模块执行npm rebuild sqlite3 --runtimeelectron --target11.0.0-beta.18 \ --disturlhttps://electronjs.org/headers --build-from-source其中--target11.0.0-beta.18必须与 scripts/package.json 中的 Electron 版本一致macOS 上还会额外注入CXXFLAGS/LDFLAGS-mmacosx-version-min10.10以保证兼容旧系统。这一步与发布流程的“Electron 版本变更检测burnthemall”是配套的一旦版本变更需要先重建原生模块再走 build → 补丁 → release 的主链路。九、发版自检清单结合手册与仓库实现一次完整发版建议按如下清单核对步骤动作对应仓库证据1npm install确认app/bg/dat/converter/node_modules存在scripts/package.json、app/bg/dat/converter/index.js2更新app/package.json的version与 release-notes 链接app/package.json3npm run buildscripts/tasks/build/build.js4手工修补scripts/node_modules/app-builder-lib/out/util/AppFileWalker.js补丁见 how-to-make-a-release.md5npm run releasemacOS/Windows 需先注入签名环境变量scripts/package.json、scripts/afterSignHook.js6检查dist/产物文件名是否已重命名为beaker-browser-*scripts/tasks/postbuild.js十、常见问题与注意事项补丁被覆盖scripts/node_modules内的AppFileWalker.js补丁在每次重新安装依赖后都会消失发布前必须重新检查、重新应用。公证失败确认afterSignHook.js中的appId与 electron-builder 配置一致且appleIdPassword使用的是 App 专用密码。自动更新比对不到新版本检查dist/产物是否已被postbuild重命名为beaker-browser-{version}...electron-updater 只认小写、无空格的文件名。converter 丢失安装包内若缺少app/bg/dat/converter/node_modules多半是补丁未应用或未检查依赖安装旧dat://数据将无法在升级后迁移。手册结尾那句轻松的“Its just that easy. Boy how about that.”背后正是上述这些容易被忽略的手工环节。对照本指南逐项执行即可把 Beaker 的发布流程稳定复现。赞分享前端【免费下载链接】beakerAn experimental peer-to-peer Web browser项目地址https://gitcode.com/gh_mirrors/be/beaker点击查看免费下载相关推荐Presenton macOS 签名 DMG 构建全流程Developer ID 签名、公证、装订与发布校验实战指南Presenton macOS 签名 DMG 构建全流程Developer ID 签名、公证、装订与发布校验实战指南 本文是 Presenton开源 AIAI 应用人工智能大模型后端前端桌面应用MCP 服务AI AgentRAG本地部署企业应用终极Windows数字许可证激活方案CMWTAT_Digital_Edition让系统激活如此简单终极Windows数字许可证激活方案CMWTAT_Digital_Edition让系统激活如此简单 在Windows系统使用过程中激活问题一直是许多用户面临桌面应用操作系统ILSpy macOS 发布全流程CI 无签名构建、离线签名公证与 DMG 打包实战ILSpy macOS 发布全流程CI 无签名构建、离线签名公证与 DMG 打包实战 本篇指南以 ILSpy 仓库中 BuildTools/packaging逆向工程开发工具桌面应用上一篇Context Hub 内容仓库完全解析Markdown Frontmatter 组织数千篇 API 文档下一篇SOEM轻量级开源EtherCAT主站解决方案完全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考