GDevelop IDE 网页版web-app构建与部署全流程解析从预检、发布到缓存清理【免费下载链接】GDevelop Open-source, cross-platform 2D/3D/multiplayer game engine designed for everyone.项目地址: https://gitcode.com/GitHub_Trending/gd/GDevelopnewIDE 目录下的web-app是 GDevelop 官方把浏览器版 IDE 发布到线上的部署工程。本文以 newIDE/web-app/README.md 为骨架结合其同目录下的三份部署脚本与 package.json完整讲解构建 → 发布 → 缓存清理的部署管线为何要先做三项安全预检、GDJS 运行时如何按版本号上传到 S3、GitHub Pages 如何发布、以及 Cloudflare 缓存如何在发版后被精确清理。读完后你可以复现整个部署流程也能基于参数速查表自定义属于你自己的发布流水线。说明newIDE/web-app/README.md本身极简仅指明这些是用于将 GDevelop IDE 作为 web-app 部署的脚本并链接到 newIDE 总 README 获取更多信息。本文的技术细节全部来自该目录下可验证的真实脚本与配置deploy.js、deploy-GDJS-Runtime.js、deploy-purge-cache.js不包含任何超出仓库证据的推测性描述。一、web-app 目录与脚本总览newIDE/web-app目录结构非常精简是典型工程化单用途部署项目newIDE/web-app/ ├── README.md # 部署说明即本文所依据的文档 ├── package.json # 部署命令与依赖声明 ├── package-lock.json # npm 依赖锁定 ├── yarn.lock # yarn 依赖锁定 └── scripts/ ├── deploy.js # 部署主入口串起整个流程 ├── deploy-GDJS-Runtime.js # 上传 GDJS 运行时与扩展到 S3 └── deploy-purge-cache.js # 调用 Cloudflare API 清理 CDN 缓存1.1 四个 npm script 命令package.json 中定义了四个脚本其中deploy是总入口npm script实际执行内容作用npm run build:appcd ../app npm run build构建浏览器版 IDEnewIDE/app基于 React 的 Create React App 工程产物输出到newIDE/app/buildnpm run deploy:gdjs-runtimenode scripts/deploy-GDJS-Runtime.js将 GDJS 运行时游戏引擎与扩展资源同步上传到resources.gdevelop-app.com对应的 S3 桶npm run deploy:purge-cachenode scripts/deploy-purge-cache.js通过 Cloudflare API 按文件清单清理 CDN 缓存npm run deploynode scripts/deploy.js部署主流程预检 → 构建 → 上传运行时 → 发布 gh-pages → 清缓存1.2 部署脚本依赖devDependencies 中锁定的工具决定了各脚本的能力边界依赖版本在部署脚本中的用途shelljs0.8.4在 Node 中执行 shell 命令构建、目录操作、S3 同步等gh-pages4.0.0把dist目录发布到 GitHub Pagesis-git-clean^1.1.0检查 git 工作区是否有未提交改动git-rev^0.2.1读取当前 git 分支名要求为masterminimist^1.2.3解析命令行参数--cf-zoneid、--skip-*等axios0.19.2发起 Cloudflare purge_cache API 请求可以看到整个部署工程刻意保持轻量不做任何自定义构建系统而是直接组合 Node 脚本 官方 CLIaws s3、gh-pages便于在任何 CI/本地环境复现。二、部署前的三项安全预检拒绝脏仓库与非生产构建deploy.js 的开头是整条管线最值得关注的部分——它不会直接开干而是先用三段 Promise 链完成三关校验全部通过才继续。这三关分别对应部署中最容易踩的三个坑误发布半成品代码、在错误分支发版、把开发版引擎带上线。2.1 第一关git 工作区必须干净deploy.js#L9-L19 使用is-git-clean检查工作区isGitClean() .then((clean) { if (args[skip-git-check]) return; if (!clean) { shell.echo( ⚠️ git repository is not clean, please clean any changes before deploying ); shell.exit(1); } })若存在未提交/未暂存的改动脚本直接以退出码 1 终止避免把未评审的改动意外发布到线上。可用--skip-git-check跳过本关详见第六节参数表。2.2 第二关只能在 master 分支部署deploy.js#L20-L33 通过git-rev读取当前分支git.branch(function (branch) { if (branch ! master) { shell.echo(⚠️ Please run deployment only from master branch); shell.exit(1); } resolve(); });这是把发布入口与代码评审分支强绑定的工程实践线上版本只允许来自受保护的主分支防止从特性分支直接发版造成线上版本与 master 不一致。2.3 第三关libGD.js / libGD.wasm 必须是生产构建deploy.js#L34-L83 对newIDE/app/public/libGD.js做了三项体检这是整个预检中最讲究的环节// 1) 文件必须存在 fs.stat(path.join(appPublicPath, libGD.js), (err, stats) { ... }); // 2) 行数不能超过 1000release 构建被压缩成极少的长行dev 构建未压缩会有数万行 const lineCount fs.readFileSync(path.join(appPublicPath, libGD.js), utf8) .split(\n).length; if (lineCount 1000) { ... exit(1); } // 3) 体积不能超过 4 MiB const sizeInMiB stats.size / 1024 / 1024; if (sizeInMiB 4) { ... exit(1); } // 4) libGD.wasm 必须存在 if (!fs.existsSync(path.join(appPublicPath, libGD.wasm))) { ... exit(1); }这段校验的注释解释了它的原理release 构建经过压缩后是几条超长行而 dev/debug 构建完全没有压缩数万行两者文件大小过于接近无法靠字节数区分因此改用行数作为判据。校验通过后会打印确认信息✅ libGD.js seems correct (X.XXMiB, N lines)。这里被检查的libGD.js/libGD.wasm正是 GDevelop 的核心所在正如 newIDE/README.md 所述IDE 使用由 GDevelop 核心 C 类编译到 JavaScript/WASM 的产物GDevelop.js来读写和处理游戏项目。也就是说第三关本质上是保证核心引擎二进制是压缩过的生产版本防止开发版引擎体积大、无优化被当作线上版发布。若缺失该文件脚本会提示你是否已编译 GDevelop.js❌ Unable to check libGD.js size. Have you compiled GDevelop.js?。三、主部署流程构建、打包与 gh-pages 发布三项预检通过后deploy.js#L84-L133 依次执行四步。3.1 步骤一构建浏览器版 IDEdeploy.js#L91-L99 调用npm run build:app即cd ../app npm run build由 Create React App 产出newIDE/app/build。可通过--skip-app-build跳过例如本地已构建过、仅想重发。3.2 步骤二部署 GDJS 运行时与扩展deploy.js#L100-L108 调用npm run deploy:gdjs-runtime。这是 IDE 在线运行游戏引擎的前提——web-app 在浏览器里预览/运行游戏时需要加载 GDJS 运行时及其扩展源码而这部分资源并不打进 IDE 的 JS 包而是独立托管在 CDN 上详见第四节。可用--skip-gdjs-runtime-deploy跳过。3.3 步骤三整理发布目录deploy.js#L110-L112 用 shelljs 重建干净的dist目录并把 IDE 构建产物拷贝进去shell.rm(-rf, dist); // 清空旧产物 shell.mkdir(-p, dist); // 重建目录 shell.cp(-r, ../app/build/*, dist); // 拷贝新构建这一步保证dist是仅含最新构建产物的快照目录避免历史残留文件被一并发布。3.4 步骤四发布到 GitHub Pagesdeploy.js#L114-L132 使用gh-pages发布ghpages.publish(dist, { history: false }, (err) { if (err) { shell.echo(❌ Finished with error:); shell.echo(err); return; } shell.echo(✅ Upload finished to GitHub.); // 若无 Cloudflare 凭据则提示手动清理否则自动清理 ... });history: false是关键配置发布时不保留历史提交等价于 force push 当前快照保证线上始终是扁平的单快照状态。发布成功后若提供了--cf-zoneid与--cf-token会立即执行缓存清理否则打印提示⚠️ You should probably purge the reverse proxy cache.。可通过--skip-deploy跳过发布例如只构建不发布。四、GDJS 运行时与扩展的上传按版本号寻址的 S3 同步deploy-GDJS-Runtime.js 负责把 GDJS 运行时游戏引擎与扩展资源上传到 S3。这段脚本揭示了 web-app 版本管理的一个巧妙设计运行时资源以版本号 hash作为目录寻址。4.1 版本号从哪来deploy-GDJS-Runtime.js#L4-L12 从newIDE/app/src/Version/VersionMetadata读取版本元数据let versionMetadata null; try { versionMetadata require(../../app/src/Version/VersionMetadata); } catch (e) { shell.echo(❌ Unable to find VersionMetadata.js in newIDE/app/src/Version - have you run npm install?); shell.exit(1); }脚本在找不到该模块时会提示是否运行过 npm install——说明VersionMetadata.js是构建流程生成的版本信息文件。与之对应newIDE/app/src/Version/index.js 中定义了getIDEVersion与getIDEVersionWithHash其中versionWithHash正是此处用于寻址的版本标识。4.2 上传命令与目标地址deploy-GDJS-Runtime.js#L14-L29 的核心只有一次aws s3 sync// 源GDJS Runtime 与扩展newIDE/app/resources/GDJS const gdjsFolder path.join(__dirname, ../../app/resources/GDJS); // 目标S3 上以版本号命名的目录 const destination s3://resources.gdevelop-app.com/GDJS-${versionMetadata.versionWithHash}; const output shell.exec( aws s3 sync ${gdjsFolder} ${destination} --acl public-read );要点拆解源目录newIDE/app/resources/GDJS包含 GDJS Runtime 及全部扩展是 IDE 运行时真正加载的游戏引擎代码。目标桶resources.gdevelop-app.com以GDJS-versionWithHash命名子目录。由于不同版本互不覆盖天然支持旧版本 IDE 仍能加载旧版本运行时的兼容性需求——已发布的旧版本 web-app 不会因新版本覆盖资源而失效。--acl public-read赋予资源公共读权限使 CDN/浏览器可以直接拉取。失败处理同步失败时打印stdout/stderr并以非零退出码终止防止引擎没传上去就继续发布。需要说明的是脚本通过 shell 直接调用aws命令shell.exec因此运行本脚本的前提是本机/CI 已安装并配置好 AWS CLI含resources.gdevelop-app.com对应账号的凭据——这一前提可以从shell.exec(aws s3 sync ...)的调用方式直接推断得出。五、Cloudflare 缓存清理精准到文件级别的 purge_cacheWeb-app 与游戏引擎资源都经过 CDN 分发发版后若缓存未失效用户会继续拿到旧版 IDE 或旧引擎。因此部署管线的收尾是 deploy-purge-cache.js——通过 Cloudflare API 精确清理指定文件而不是整站刷新。5.1 必需参数deploy-purge-cache.js#L5-L11 要求两个参数缺失即退出--cf-zoneid Cloudflare Zone ID站点区域标识 --cf-token Cloudflare API Token鉴权令牌5.2 请求构造deploy-purge-cache.js#L14-L40 构造了一个指向 Cloudflare v4 API 的purge_cache请求const zoneId args[cf-zoneid]; const purgeCacheUrl https://api.cloudflare.com/client/v4/zones/${zoneId}/purge_cache; axios.post( purgeCacheUrl, { files: [ // 更新 index.html https://editor.gdevelop.io/, https://editor.gdevelop.io/index.html, // 清理 service worker否则旧 service worker 会继续提供旧 index.html https://editor.gdevelop.io/service-worker.js, // 清理 libGD.js避免不兼容 https://editor.gdevelop.io/libGD.js, https://editor.gdevelop.io/libGD.mem, // 其他文件 https://editor.gdevelop.io/manifest.json, ], }, { headers: { Authorization: Bearer ${args[cf-token]}, Content-Type: application/json, }, } )脚本注释解释了每个文件为何必须清理index.html是页面入口必须刷新service-worker.js若不清旧 service worker 会继续把旧版 index.html 提供给用户——这是 PWA 应用发版后最常见的永远看不到新版问题的根源libGD.js/libGD.mem是核心引擎二进制清理是为了避免新旧 index.html 与引擎版本不匹配导致的不兼容manifest.json属于 PWA 清单文件一并刷新。请求成功打印✅ Cache purge done.失败则提示检查标识符是否正确are your identifiers correct?并以退出码 1 终止。六、deploy 命令参数速查表综合 deploy.js 与 deploy-purge-cache.js 中的minimist解析逻辑npm run deploy -- 参数支持的全部参数如下参数作用于含义--skip-git-checkdeploy.js跳过 git 工作区干净检查第一关--skip-app-builddeploy.js跳过npm run build:app使用已存在的构建产物--skip-gdjs-runtime-deploydeploy.js跳过 GDJS 运行时与扩展的 S3 上传--skip-deploydeploy.js只构建不发布不上传 gh-pages--cf-zoneid iddeploy.js / deploy-purge-cache.jsCloudflare Zone ID提供后发版自动清理缓存--cf-token tokendeploy.js / deploy-purge-cache.jsCloudflare API Token与--cf-zoneid成对出现典型的生产部署命令形如cd newIDE/web-app yarn deploy -- --cf-zoneid YOUR_ZONE_ID --cf-token YOUR_API_TOKEN本地联调时则可组合跳过参数快速迭代cd newIDE/web-app npm run deploy -- --skip-git-check --skip-app-build --skip-deploy注意deploy.js只有在同时提供--cf-zoneid与--cf-token时才会自动调用deploy:purge-cache二者缺一则只会打印你应该清理反向代理缓存的提示。而直接运行npm run deploy:purge-cache时二者必须提供否则脚本直接退出。七、触发方式与配套文档7.1 一键入口newIDE/README.md#L175-L182 的 Webapp version 小节给出了 web-app 的完整触发方式cd newIDE/web-app yarn deploy # 或 npm run deploy并明确说明该命令的副作用这也会上传 IDE 所需的游戏引擎GDJS与扩展源码并清理 CloudFlare 缓存——与本文逐段拆解的脚本行为完全一致。7.2 与 IDE 工程的关系浏览器版 IDE 与桌面版共用同一套 newIDE/app 编辑器代码基于 React、Material-UI、Pixi.js、Three.js 构建web-app 部署只是把这份代码以 CRA 产物形式发布到网页。桌面版Electron的构建与发布则是另一条独立流程详见 newIDE 总 README 的 Building and deploying the standalone app 一节本文所依据的 web-app README 正是该总 README 中部署章节在 web-app 场景下的落点。八、部署管线时序总览把整条管线按时间顺序串联一次完整发布的过程如下git 工作区干净? ──否── 退出(1) │是 当前分支 master? ──否── 退出(1) │是 libGD.js 行数≤1000 ≤4MiB libGD.wasm 存在? ──否── 退出(1) │是 npm run build:app ── newIDE/app/build │ npm run deploy:gdjs-runtime ── aws s3 sync app/resources/GDJS │ └── s3://resources.gdevelop-app.com/GDJS-versionWithHash (--acl public-read) │ rm -rf dist mkdir dist cp ../app/build/* dist │ gh-pages publish(dist, { history: false }) │ 提供了 cf-zoneid/cf-token? ──否── 提示手动清理缓存 │是 Cloudflare purge_cacheindex.html / service-worker.js / libGD.js / libGD.mem / manifest.json小结newIDE/web-app是一个小而完整的发布工程范本三段式安全预检防止错误发布history: false的 gh-pages 发布保证线上快照干净按versionWithHash寻址的 S3 目录保障引擎资源的版本兼容最后以文件级别的 Cloudflare 缓存清理尤其是service-worker.js解决 PWA 发版后缓存顽固这一经典痛点。如果你想在本地验证这套流程最轻量的方式是cd newIDE/web-app npm install后用npm run deploy -- --skip-git-check --skip-app-build --skip-deploy观察完整预检与构建日志再逐步放开参数完成真实发布。【免费下载链接】GDevelop Open-source, cross-platform 2D/3D/multiplayer game engine designed for everyone.项目地址: https://gitcode.com/GitHub_Trending/gd/GDevelop创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考