开发工具桌面应用【免费下载链接】desktopFork of GitHub Desktop to support various Linux distributions项目地址https://gitcode.com/gh_mirrors/des/desktop点击查看免费下载导读本文基于 GitHub Desktop 仓库中一份仍在演进中的规划文档 docs/technical/future-repository-structure.md梳理该项目对app/src源码目录的目标组织方案哪些模块应当跨 Webpack bundle 共享、哪些逻辑应当归属到哪个进程或入口以及 renderer 内部各个子目录的职责边界。文章会逐条对照文档中规划的目录与实际仓库现状并结合 app/webpack.common.ts、main-process、cli、highlighter等入口源码给出可验证的落地证据帮助新贡献者快速理解代码该放哪里、谁能消费它这一核心问题。一、文档背景与定位一份进行中的结构蓝图文档开篇即声明这是一份work in progress进行中的文档它回答的问题是在 GitHub Desktop 源码中事物应该在哪里被发现、代码将如何被组织。同时作者给出了两条重要约束该文档会随时间持续更新因为这是一次渐进式的重构incremental process存在大量未知数重构期间不能停止发布功能we want to continue to ship features while doing this work即目录调整必须与持续交付并行推进。因此本文档描述的是一种目标态而非现状。读者在对照代码时应以文档规划 仓库现状双重视角阅读规划用于指导新代码的落位现状则反映迁移尚未完成的部分。从文档结构看规划分两大层次共享模块Shared Modules可被 Desktop 生成的任何 Webpack bundle 复用的代码应用 BundleApplication Bundles每个 bundle 目录下会有一个特定入口文件由 Webpack 配置转译打包。二、共享模块models与lib的职责划分文档将可跨 bundle 共享的模块限定在两个目录app/src/models—— 纯数据结构包含代码库中用于表示常见对象的形状shapes。它们应当是immutable不可变且 plain朴素/无副作用的。从 app/src/models 目录的现状来看这一规划已经落地branch.ts、commit.ts、repository.ts、pull-request.ts、merge.ts、rebase.ts、tip.ts、status.ts等文件全部是领域对象的类型定义与轻量构造逻辑不依赖具体运行环境。以commit.ts中的提交对象、account.ts中的账户模型为例它们既被主进程、渲染进程引用也被 CLI 和测试引用因此必须保持纯——只描述数据不携带平台相关行为。app/src/lib—— 环境无关的函数包含不依赖在特定环境中执行的函数。这里的特定环境主要指 Electron 主进程、渲染进程、Web Worker、Node CLI 等执行上下文。app/src/lib 中大量工具函数符合该约束例如fuzzy-find.ts模糊匹配算法format-date.ts、format-duration.ts、format-relative.ts格式化工具parse-app-url.ts、remote-parsing.ts、sanitize-ref-name.tspath.ts、clamp.ts、promise.ts等纯工具这些模块被各 bundle 共享时不会引入 DOM、window、process.platform等环境依赖平台相关的判断通过 Webpack 替换在构建期完成详见后文对globals.d.ts的说明。文档补充约定bundle 内部也需要models/lib文档特别指出对于与某个特定 bundle 关联、且不打算跨 bundle 共享的逻辑或功能应当遵循同样的模式放在该 bundle 目录内部的models或lib子目录中。也就是说共享是分层决策全局共享放app/src/models与app/src/lib局部共享/专属逻辑放各 bundle 内的models/lib。这一约定直接体现在下面的 renderer 目录规划中。三、应用 BundleWebpack 配置视角下的五个入口文档称这些目录为bundles束因为 Webpack 配置会对每个目录中的特定文件做转译生成打包与运行应用所需的内容。我们之所以称这些文件夹为 bundles是因为我们的 webpack 配置会对每个目录中的一个特定文件进行转译以生成打包和运行应用所需的内容。对照 app/webpack.common.ts 可以精确验证这一定义——每个 bundle 对应一个entry并注入一个区分进程种类的替换变量__PROCESS_KIND__Bundle目录规划文档实际入口webpack.common.tstarget主进程app/src/mainsrc/main-process/mainelectron-main用户界面app/src/renderersrc/ui/indexelectron-renderer高亮 Workerapp/src/highlightersrc/highlighter/indexwebworker崩溃窗口app/src/crashsrc/crash/indexelectron-renderer命令行接口app/src/clisrc/cli/mainnode这里有一个值得注意的细节文档规划中的目录名main、renderer与仓库实际目录名main-process、ui并不完全一致。这恰恰印证了文档进行中、会随实现调整的定位——规划给出的是目标态命名而当前仓库仍沿用旧命名如 app/src/main-process/main.ts、app/src/ui/index.tsx。本文后续引用一律以仓库现状路径为准。下面逐一解读五个 bundle。四、主进程 Bundleapp/src/main现状为app/src/main-process文档定位为主进程打包的模块与逻辑是用户启动 Desktop 的入口点。主进程是 Electron 应用中唯一拥有操作系统级能力的进程负责创建窗口、菜单、系统托盘、原生通知、协议处理、自动更新等。从 app/src/main-process/main.ts 的导入清单可以看到典型的主进程职责创建应用窗口AppWindow、构建默认菜单buildDefaultMenu处理 Squirrel 更新事件handleSquirrelEventWindows 安装/卸载钩子安装 IPC 处理器ipc-main安装全局异常上报exception-reporting、未捕获异常展示show-uncaught-exception读取标题栏配置readTitleBarConfigFileSync等平台相关操作主进程目录下的子模块如 app/src/main-process/menu也遵循bundle 专属逻辑就近存放的约定菜单构建、上下文菜单等逻辑只服务于主进程不进入共享的lib。五、用户界面 Bundleapp/src/renderer现状为app/src/ui——文档着墨最多的部分文档明确指出渲染进程负责显示用户界面并处理 Desktop 中的大部分数据管理。由于这是当前代码库中体量最大的部分the largest part of the current codebase文档专门为其勾画了目标目录结构app └── src └── renderer ├── components │ ├── dialogs │ ├── primitives │ └── text ├── lib │ └── git ├── models ├── stores └── views作者坦承关于如何组织 React 项目有大量观点存在因此这份规划刻意聚焦于解决以下四个实际问题更好地组织 React 组件components更好地组织渲染进程所需模块lib厘清哪些模块可在应用各部分之间共享、哪些应保持局部专属反映当前真实的使用模式——Git 操作发生在渲染进程、store 在渲染进程创建与管理5.1components—— React 组件包含应用中使用的 React 组件。组织方式上没有强烈意见但更好的组织能简化其他地方的 import。文档还提到了基于现有组件可能形成的子目录分组dialogs、primitives、text。对照现状 app/src/ui该规划在仓库中体现为大量按业务域划分的组件目录changes/、history/、branches/、diff/、banners/、toolbar/、dialog/等而文档提到的三类新分组在现有代码中也有对应物例如dialog/对话框基座、octicons/等基础组件、commit-message/、text类展示组件。规划的本质是让目录名自解释从而简化import路径并降低新贡献者的定位成本。5.2lib与lib/git—— 渲染进程专属逻辑与 Git 功能lib渲染进程专属的函数与逻辑lib/git当前的 Git 功能本地化用于渲染进程这一规划在现状中的对应物是 app/src/ui/lib 与 app/src/lib/git。注意这里存在文档规划与现状的错位Git 模块当前位于共享层app/src/lib/git而文档希望它未来归入 renderer 的lib/git。原因是 Git 操作目前在 Desktop 中实际由渲染进程发起执行文档reflect our current usage patterns的第一条即Git operations performed in the renderer。可以用引用关系验证这一点app/src/ui/app.tsx、app/src/ui/app-error.tsx、app/src/ui/missing-repository.tsx 等渲染进程组件都直接from ../lib/git引入 Git 工具说明 Git 逻辑的主要消费方就是 UI 层。规划希望把这种事实上的归属显式化。5.3models—— 渲染进程专属的数据类型渲染进程专属的接口与类。与共享层app/src/models的全局可复用形状不同这里的models只服务渲染进程。现状中 UI 层没有独立的models目录相关类型大多仍集中在共享层或各组件目录内——这属于文档描述的渐进迁移尚未完成的部分。5.4stores—— 从lib/stores迁移而来的状态管理层现有的 store 集合来自lib/stores。现状中 store 确实位于共享层 app/src/lib/storesapp-store.ts、repositories-store.ts、accounts-store.ts、sign-in-store.ts、pull-request-store.ts、git-store.ts、commit-status-store.ts、notifications-store.ts等一应俱全。文档的目标是把它们迁入 renderer 的stores目录——这与stores created and managed in the rendererstore 在渲染进程创建与管理的现状模式一致。5.5views—— 基于仓库状态渲染的顶层组件文档给出了非常具体的清单views是顶层组件我们根据仓库的状态渲染它们 ——repository.tsx、cloning-repository.tsx和missing-repository.tsx。对照现状可以精确验证app/src/ui/repository.tsx —— 仓库主视图常规状态app/src/ui/cloning-repository.tsx —— 克隆进行中的视图app/src/ui/missing-repository.tsx —— 仓库缺失/无法访问时的视图这印证了视图由仓库状态驱动的设计Desktop 根据当前选中的仓库处于正常 / 克隆中 / 缺失哪种状态决定渲染哪一个顶层组件。5.6 入口文件约定文档最后补充入口index.tsx应保留在根目录其他所有文件都应移动到磁盘上更合适的位置。现状中 app/src/ui/index.tsx 正是渲染进程的 Webpack 入口对应webpack.common.ts中entry: { renderer: path.resolve(__dirname, src/ui/index) }其余组件/工具均已下沉到各自业务目录——这一约定已基本实现。六、高亮 Worker Bundleapp/src/highlighter文档定位Desktop 初始化该 Web Worker用于对 diff 中的代码进行异步语法高亮计算。对照 app/src/highlighter/index.ts其实现细节完全吻合它不导入完整的 CodeMirror而是只引入codemirror/addon/runmode/runmode.node.js这一最小子集This hack is brought to you by webpack通过getMode/innerMode/StringStream在 Worker 上下文中运行 CodeMirror 的 mode 完成分词。这与 app/webpack.common.ts 中 highlighter 的专门配置互为印证target: webworker—— 明确打包为 Worker通过resolve.alias将codemirror替换为runmode.node.js精简版使用独立的 app/src/highlighter/tsconfig.json 编译按 CodeMirror mode 拆分 chunksplitChunks.cacheGroups.modes实现按需加载各语言模式。可见独立目录 独立入口 独立打包配置正是文档所定义的 bundle 形态的典型样本。七、崩溃窗口 Bundleapp/src/crash文档定位Desktop 用于在未处理错误导致主应用崩溃时展示默认 UI 的模块与逻辑。现状中 app/src/crash 包含crash-app.tsx、index.tsx、shared.ts以及样式 app/src/crash/styles/crash.scss。Webpack 侧对应 app/webpack.common.ts 中crash配置以src/crash/index为入口、输出crash.html、注入__PROCESS_KIND__ crash。它被设计成一个独立、轻量的渲染进程 bundle确保主进程异常时仍能拉起一个可用的错误提示界面而不是黑屏。八、命令行接口 Bundleapp/src/cli文档定位为github命令行接口打包的模块与逻辑用户可以为 Desktop 启用该命令。现状中 app/src/cli 的结构清晰对应文档规划app/src/cli/main.ts —— CLI 入口使用mri解析参数默认命令为openapp/src/cli/commands —— 子命令实现clone.ts、open.ts、help.tsapp/src/cli/load-commands.ts —— 命令注册表app/src/cli/util.ts —— 命令错误与参数整理工具。Webpack 侧对应cli配置以src/cli/main为入口、target: node因此 CLI 被打包为独立的 Node 程序而非 Electron 应用——这与文档为github命令打包的定位一致。九、为什么要做这些迁移——文档给出的三个理由在读完目录规划后文档以Why move all this stuff around?为题正面回应现有代码能正常工作为什么要折腾的质疑给出三条理由代码库在交付压力下有机生长grown organically over time amid the pressures of shipping现在是最好的时机去重新审视并质疑项目早期的假设代码库已足够复杂关于东西该放哪里的困惑正在蔓延团队已积累足够经验来建立结构随着新贡献者不断加入需要让代码该放哪里、哪些模块可被谁消费比今天更显而易见并构建工具来保证代码组织与打包方式在逻辑上一致build tooling to ensure things are logically organized for how we build and package Desktop。第 3 条中的tooling在仓库中已有部分实现痕迹例如 docs/technical/placeholders.md 与 app/src/lib/globals.d.ts 通过全局占位符约束哪些标识符可以在构建期被替换app/webpack.common.ts 通过getReplacements()统一注入各 bundle。这些机制保证了即便目录继续演进打包产物仍保持一致。十、从规划到现状一份对照清单总结结合全文将文档规划与当前仓库现状整理为对照表方便新贡献者按图索骥文档规划目录当前仓库路径实际职责关键文件app/src/models共享app/src/models不可变、朴素的数据形状repository.ts、commit.ts、branch.tsapp/src/lib共享app/src/lib环境无关的函数fuzzy-find.ts、format-date.tsapp/src/mainapp/src/main-process主进程入口与专属逻辑main.ts、app-window.tsapp/src/rendererapp/src/ui渲染进程 UI 与数据管理index.tsx、app.tsxrenderer/componentsapp/src/ui 下的业务目录React 组件changes/、history/、dialog/renderer/lib/gitapp/src/lib/git待迁移渲染进程使用的 Git 操作core.ts、checkout.ts、log.tsrenderer/storesapp/src/lib/stores待迁移状态管理 storeapp-store.ts、repositories-store.tsrenderer/viewsapp/src/ui/repository.tsx 等按仓库状态渲染的顶层组件repository.tsx、cloning-repository.tsx、missing-repository.tsxapp/src/highlighterapp/src/highlighterdiff 语法高亮 Web Workerindex.tsapp/src/crashapp/src/crash崩溃兜底 UIcrash-app.tsx、index.tsxapp/src/cliapp/src/cligithub命令行接口main.ts、commands/两点阅读提醒目录命名存在差异文档中的main/renderer对应现状的main-process/ui规划是目标态现状仍用旧名部分模块仍在共享层Git 工具与 store 当前位于app/src/lib/git与app/src/lib/stores文档规划它们迁入 renderer 内部迁移尚未完成——这正是文档反复强调incremental process的原因。理解了这张对照表就掌握了 GitHub Desktop 代码组织的核心心智模型共享层放纯数据与环境无关逻辑bundle 层按进程/入口划分专属代码renderer 内部再按组件、工具、模型、store、视图分层。无论是定位某个功能的实现、判断新代码应该放哪里还是理解 Webpack 打包边界都可以从这份规划与现状的对照中快速找到答案。赞分享开发工具桌面应用【免费下载链接】desktopFork of GitHub Desktop to support various Linux distributions项目地址https://gitcode.com/gh_mirrors/des/desktop点击查看免费下载相关推荐GitHub Desktop 源码仓库结构演进从 app/src 到未来目录规划与 Webpack Bundle 架构GitHub Desktop 源码仓库结构演进从 app/src 到未来目录规划与 Webpack Bundle 架构 本篇技术指南围绕 docs/techn桌面应用版本控制开发工具Elementor Editor Styles Repository 源码解析编辑器样式仓库架构与演进Elementor Editor Styles Repository 源码解析编辑器样式仓库架构与演进 导读 elementor/editor stylesCMS前端后端低代码nhost 仓库中的 safeexec 模块规避 Windows 下 exec.LookPath 当前目录查找漏洞的实现解析nhost 仓库中的 safeexec 模块规避 Windows 下 exec.LookPath 当前目录查找漏洞的实现解析 本篇技术指南围绕 nhost 仓后端认证鉴权数据库无服务开发工具云原生上一篇Cargo 集成测试编写完全指南从 Functional Tests 到 UI Snapshot 测试下一篇Cypress 开源仓库全解从 npm 安装到二进制构建、monorepo 结构与贡献流程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考