企业官网建设流程全解析

Joplin GSoC 2022 项目提案全解：14 个选题、难度与工作量，及其在仓库中的落地印证

【免费下载链接】joplinJoplin - the privacy-focused note taking app with sync capabilities for Windows, macOS, Linux, Android and iOS.项目地址: https://gitcode.com/GitHub_Trending/jo/joplin

Joplin 在 2022 年第三次参与 Google Summer of Code，readme/dev/gsoc/gsoc2022/ideas.md收录了当年官方发布的 14 个项目提案（ideas），每个提案都包含背景描述、预期成果、难度、所需技能、导师与预估工时。本文完整解读这 14 个选题及其技术要点，并结合当前 Joplin 仓库中已存在的对应模块（插件构建体系、PDF 查看器、桌面集成测试、文档构建器等）逐一印证这些提案在源码中的落地形态，帮助开发者评估选题、理解实现路径，也为想参与 Joplin 贡献的申请者提供一份可检索的参考。

一、背景：2022 年 GSoC 的主题与两条主线

2022 是 Joplin 第三年参与 Google Summer of Code（GSoC）。当年的两大主题方向是：

• 移动端与平板开发（Mobile and tablet development）——改进 iOS 与 Android 上的移动/平板应用体验；
• 插件与外部应用（Plugin and external apps）——利用 Joplin API 构建插件和外部应用；
• 同时欢迎申请者提出自己的原创想法。

提案文档明确强调：这 14 个提案本身就是"proposal"性质的开放选题，团队公开欢迎全新的创意。如果有列表之外的想法，官方建议的做法是尽早与导师取得联系，确认项目现实可行且落在 Joplin 的项目范围内。

对候选贡献者的关键提醒

文档在 "Information for Contributors" 一节给出的建议值得所有开源申请者注意：

1. 这些想法由开发者和用户共同贡献，有时表述模糊或不完整。基于某个想法提交 GSoC 提案前，强烈建议先主动联系开发者，弄清楚该选题的具体细节。
2. GSoC 的竞争相当激烈。被录用的贡献者通常对提案项目的技术栈做过充分调研，并且与潜在导师保持频繁沟通。文档直言："Simply copying and pasting an idea here will not work"——仅仅照抄页面上的一个想法是没有用的；但反过来，完全不先咨询导师就凭空捏造一个新想法，同样很难成功。

配套的两份文档在仓库中均可查证：构建说明见 BUILD.md，当年 GSoC 的 Pull Request 规则见 pull_request_guidelines.md。

二、插件体系类提案

提案 1：移动端插件系统（Plugin system on mobile）

背景：插件系统当时只在桌面端和 CLI 可用。团队认为它在移动端同样可行，但需要做两方面工作：一是让插件 API 与移动端兼容，二是实现一套在移动端加载插件的机制。

预期成果：允许在移动端加载并运行插件。难度：High。所需技能：TypeScript、React Native。预估工时：350 小时。导师：PackElend、Roman、Laurent。

仓库印证：移动端目前已有插件相关基础设施，例如 PluginAssetsLoader.ts 实现了将插件资源文件（以 base64 打包进pluginAssets/index）写入pluginAssetDir配置目录的流程，并通过 KvStore 记录资源 hash 以避免重复拷贝；桌面/CLI 侧则已有完整的插件加载与安装机制。从源码结构看，移动端目前落地的是"资源导入"这一环，完整的插件运行时仍是移动端侧需要补齐的部分。

提案 4：桌面端内置默认插件（Implement default plugins on desktop application）

背景：希望将 Backup、Rich Markdown 等插件直接随桌面应用一起发布。需要实现一套流程，让默认插件被打包进去并自动更新；必须考虑 CI 环境下的行为、跨平台差异，并且流程要容错、失败时能重试。

预期成果：一套将指定插件随 Joplin 版本发布的系统，以及配套的打包说明文档。难度：High。所需技能：TypeScript、JavaScript、Electron 与 GitHub Actions 知识。预估工时：350 小时。导师：CalebJohn、JackGruber。

仓库印证：该提案在仓库中已落地为独立的 packages/default-plugins 包。核心构建脚本 buildDefaultPlugins.ts 从 pluginRepositories.json 读取插件清单，对每个插件按两种类型处理：

• git 构建型：执行git clone→ 切换分支 →git checkout <commit>精确到清单中锁定的 commit（checkout 失败会先git fetch再重试，最后还会用getCurrentCommitHash()校验实际 commit 是否一致），把源码复制到临时目录后执行npm install --no-audit --no-fund --prefer-offline（注释说明该命令在 Windows CI 上偶发STATUS_STACK_BUFFER_OVERRUN崩溃，因此设置了retryCount: 3），最后收集publish/*.jpl产物拷贝到输出目录；
• npm 发布型：直接从node_modules中已发布包的publish/目录复制.jpl文件。

清单中还支持通过plugin-patches/目录下的补丁文件对克隆下来的源码打补丁（git apply），当前 pluginRepositories.json 中列出的io.github.jackgruber.backup即对应提案中提到的 Backup 插件，io.github.personalizedrefrigerator.js-draw则以 npm 包方式引入。这套实现完整覆盖了提案要求的"打包、自动更新（随版本发布）、CI 容错与重试"。

提案 11：改进插件搜索与可发现性（Improve plugin search and discoverability）

背景：随着插件数量增长，需要改进插件的发现与搜索体验，尤其是搜索相关性。文档列出了三个具体目标：

• 在官网plugins路径下建立一个列表页，展示推荐插件、热门插件等（类似 Firefox 附加组件目录），并支持搜索；
• 每个插件拥有独立详情页，展示来自manifest.json的插件信息；如果 manifest 中链接了 README，可以考虑抓取并一并展示；
• 应用内部利用stats.json对插件排序，例如下载量多的排前面。

文档指出，以上功能都可以基于插件仓库（plugin repo）中的信息实现，特别是manifests.json与stats.json两个文件；并且官网插件页面应当由脚本动态生成，并集成到 CI 中。

预期成果：主要——自动生成、托管于官网plugins路径的网站；次要——桌面应用内的插件搜索体验改进。难度：Medium。所需技能：TypeScript、CSS、GitHub Actions。预估工时：350 小时。导师：JackGruber、Laurent。

仓库印证：插件仓库数据管道已有对应实现：packages/default-plugins/pluginRepositories.json 维护内置插件清单，packages/plugins/ToggleSidebars是仓库内维护的插件示例。文档侧，Docusaurus 配置 docusaurus.config.js 的导航栏中已存在指向plugins路径的独立入口（并注释说明该 URL 已让位于插件发现网站），插件清单与构建脚本的分离结构也为"由脚本动态生成官网页面"提供了基础。

提案 12：邮件插件（Email plugin）

背景：开发一个通过 IMAP 拉取邮件、并把邮件转换成笔记（含附件）的插件，插件要能过滤要下载哪些邮件（例如按文件夹过滤）。

文档列出的可选扩展功能：

• 支持多个邮件账户；
• HTML 转 Markdown；
• 删除/移动已收到的邮件。

预期成果：上述功能的 Email 插件可从插件仓库安装。难度：Medium。所需技能：TypeScript、JavaScript。预估工时：350 小时。导师：Roman、Laurent。

仓库印证：插件生态侧，仓库自带 ToggleSidebars 插件 作为插件结构参考；邮件转笔记涉及的 HTML 转 Markdown 能力，仓库中已有 import-enex-html-gen.ts 与 HtmlToMd.ts 等可参考的转换实现。

三、桌面应用类提案

提案 2：无缝的桌面应用更新（Seamless desktop application updates）

背景：桌面应用当时支持自动更新，但流程并不顺滑：用户会看到模态对话框，需要点击"Download"，随后打开默认浏览器下载文件，再手动运行安装包走一遍安装流程。

文档期望的改进点：

• 安装包应该在后台自动下载；
• 下次启动应用时自动完成安装；
• 至少要在 Windows 和 macOS 上生效（Linux 由于分发渠道多样，可能需要特殊处理）。

预期成果：应用告知用户有可用更新；若用户选择应用更新，安装程序在下一次启动时于后台全自动完成更新过程；同时需要探索"热更新（live update）"是否可行，以及当被替换的文件正在被占用时如何化解冲突。难度：Medium。所需技能：TypeScript、React，以及一定的 Electron 与 electron-builder 知识。预估工时：175 小时。导师：CalebJohn。

仓库印证：当前桌面端的更新检查逻辑位于 checkForUpdates.ts。从源码结构看，它通过shim.fetch拉取objects.joplinusercontent.com/r/releases上的发布列表，用compare-versions比较版本，并用 KvStore 中的updateCheck::skippedVersions记录用户跳过的版本——即"检查与提示"环节已具备，提案所指的后台下载安装与自动更新流程属于该链路的延伸改造。

提案 7：改进 PDF 导出（Improve PDF export）

背景：Joplin 的 PDF 导出依赖 Chrome 内置的 print to PDF 功能，限制很多。改用第三方库把笔记转成 PDF 可以改善这一现状，该改进同时适用于桌面版与 CLI 版。

文档列出的潜在收益：

• 多条笔记导出为单个 PDF；
• 在 PDF 中嵌入附件；
• 支持延迟导出，等待笔记完全渲染完成后再导出（便于插件先完成渲染）。

预期成果：PDF 导出不再依赖 Chrome 的 print to pdf。难度：Medium。所需技能：TypeScript、JavaScript。预估工时：350 小时。导师：Roman、CalebJohn。

提案 8：用第三方库替换内置 PDF 渲染器（Replace built-in PDF renderer）

背景：与导出同理，Joplin 展示 PDF 附件时依赖内置 PDF 渲染器。替换为第三方库的好处包括：

• 笔记重新渲染时可以保留 PDF 查看器状态。文档举例：当前打开并关闭设置面板后，PDF 会回到第 1 页；
• 有可能支持跳转到 PDF 的指定页甚至指定位置；
• 可以在 Joplin 内对 PDF 文档做批注。

预期成果：使用第三方库来渲染 PDF。难度：Medium。所需技能：TypeScript、JavaScript。预估工时：350 小时。导师：Roman、CalebJohn。

仓库印证：该提案在仓库中落地为独立的 packages/pdf-viewer 包——按 README.md 说明，这是一个为 Joplin 自建的 PDF 查看器，设计为在 iframe 中渲染，用 webpack 构建并输出到/dist，由app-desktop的构建流程负责把产物拷贝到位。包内FullViewer.tsx/VerticalPages.tsx/Page.tsx/PdfDocument.ts/hooks/等结构体现了"多页布局 + 文档状态管理"的自定义实现，正是提案中"保留查看器状态"目标的技术载体；pdfSource.test.ts 则提供了对应的测试用例。

提案 13：桌面应用集成测试（Desktop application integration testing）

背景：桌面应用前端当时只有少量单元测试（验证 React hooks 与某些工具函数），没有集成测试来防止"改动一个组件却破坏另一个组件"的问题。项目目标是搭建桌面应用的集成测试体系，完成环境配置并编写若干测试证明体系可用。

预期成果：学生掌握桌面应用自动化测试的搭建方法，并至少为应用的一个子集（例如 Markdown 编辑器与 WYSIWYG 编辑器）实现自动化测试。难度：High。所需技能：TypeScript、JavaScript、Electron。预估工时：350 小时。导师：CalebJohn、Laurent。

仓库印证：该提案已落地为 packages/app-desktop/integration-tests 目录，采用 Playwright 体系（playwright.config.ts、run-ci.sh）。测试用例覆盖了提案中点名的编辑器之外的大量场景，如 main.spec.ts、markdownEditor.spec.ts、richTextEditor.spec.ts、noteList.spec.ts、settings.spec.ts、pluginApi.spec.ts 等，说明"组件间联动回归"这一原始动机已被持续扩展成完整的桌面集成测试矩阵。

四、编辑器类提案

提案 5：为移动端 Beta 代码编辑器实现工具栏（Implement a toolbar for the mobile beta code editor）

背景：Beta 代码编辑器（基于 CodeMirror）计划成为主编辑器，为此需要做若干改动，其中最重要的是添加工具栏，用于设置 Bold、无序列表、Header 等各种格式。此外还要修复一系列 bug 才能让编辑器达到生产可用标准——文档指出这些 bug 都列在 issue 列表中（带 "high" 和 "mobile" 标签）。

预期成果：主要——新的移动端编辑器工具栏；次要——修复 Beta 编辑器中的 bug。难度：High。所需技能：TypeScript、JavaScript、React Native、React Hooks，还需要学习 CodeMirror 6。预估工时：350 小时。导师：CalebJohn、Laurent。

仓库印证：仓库中已存在完整的 CodeMirror 6 封装层 packages/editor/CodeMirror，包括 createEditor.ts、CodeMirrorControl.ts、editorCommands/、extensions/以及配置从设置项映射的 configFromSettings.ts。从源码结构看，编辑器的"命令 + 扩展"组织方式正是实现工具栏按钮（Bold、列表、标题切换等）的标准落点；配套的 CodeMirrorControl.test.ts 与testing/目录提供了测试支撑。

提案 6：改进富文本/WYSIWYG 编辑器的集成（Improve integration of the richtext/WYSIWYG editor）

背景：Joplin 提供与 Markdown 编辑器并行的富文本/WYSIWYG 输入体验，但与整体应用的集成仍有多个可改进点。文档点名了三个方向：

• 提高与 Joplin 全局快捷键的兼容性（很多快捷键目前仍是静态的）；
• 收敛编辑器中与 Markdown 格式不兼容的功能；
• 降低在两种编辑器之间切换时数据变化带来的影响。

文档还提示申请者去阅读官网关于该编辑器局限性说明的专门页面。

预期成果：移除不可用的格式选项，对齐 Joplin 通用的编辑器选项，并整体提升编辑器易用性。难度：High。所需技能：TypeScript、JavaScript、CSS、HTML、Markdown 渲染，并需要学习 TinyMCE。预估工时：175 小时。导师：Daeraxa。

仓库印证：桌面端 WYSIWYG 编辑器基于 TinyMCE 的裁剪版本，仓库 Assets/TinyMCE/JoplinLists 保存了定制的列表实现与配套资源（含 4 个 JSON 配置与源码），checkForUpdates.ts 所在目录外的 app-desktop/integration-tests/richTextEditor.spec.ts 则提供了针对该编辑器的集成测试，可用于验证"编辑器切换后数据一致性"类改动。

五、移动端与同步类提案

提案 9：在 Android 上重建文件系统同步（Rebuild file system sync on Android）

背景：一次 Android 系统更新破坏了文件系统同步——应用访问存储被要求改用新 API，而当时没有能将该 API 代理给 React Native 的现成库。要让文件系统同步重新可用，必须从头编写。

预期成果：文件系统同步在所有 Android 版本上可用。难度：High。所需技能：Android、Java/Kotlin、TypeScript。预估工时：175 小时。导师：Roman。

仓库印证：移动端原生桥接层的现状可以佐证该问题的复杂性——packages/react-native-saf-x（Storage Access Framework 的 React Native 封装，含 Android Java 实现与bob.config.js生成配置）与 packages/react-native-alarm-notification 都是仓库自维护的 RN 原生模块，说明 Joplin 对 Android 新存储 API 的适配正是沿着"自研原生模块代理系统 API"的路线推进；同步目标抽象则集中在 SyncTargetFilesystem.ts 与各端 fs-driver（如 fs-driver-node.ts）之上，Android 侧重建的关键就是在 React Native 层补上对 SAF 的调用桥。

提案 10：平板布局（Tablet layout）

背景：在平板等宽屏设备上，Joplin 可以采用不同的布局——例如始终显示笔记列表，或者编辑区与预览区同时可见。各组件的显示应该是可选的：比如用户可能想保留笔记列表但隐藏侧边栏。同时，这一改动必须以不破坏现有移动端布局的方式实现。

预期成果：新的平板专用布局，侧边栏、笔记列表与编辑器同时可见。难度：High。所需技能：React、TypeScript、CSS。预估工时：350 小时。导师：Laurent。

仓库印证：桌面端已存在的多栏布局机制是平板布局的直接参考：packages/plugins/ToggleSidebars 提供侧边栏显隐的插件化控制，app-desktop/integration-tests/resizableLayout.spec.ts 覆盖可调节布局的集成测试，而移动端侧边栏相关的状态与工具函数可参见 folders-screen-utils.ts。

提案 14：客户端设置同步（Client settings sync）

背景：当前在一个客户端上修改设置后，不会同步到连接同一同步目标的其他客户端。该项目要在现有同步功能基础上创建客户端间的设置同步，实现"一套配置走天下"——例如键盘快捷键、已安装插件、Markdown 插件、笔记历史等，避免在每个客户端上重复设置。

预期成果：通过现有同步机制，同时同步跨平台通用选项与各平台特有选项。难度：High。所需技能：TypeScript、JavaScript。预估工时：350 小时。导师：Daeraxa、JackGruber、Laurent。

仓库印证：Joplin 的同步架构核心在 Synchronizer.ts，各同步目标（Joplin Cloud、Nextcloud、WebDAV、OneDrive、Amazon S3 等）都继承自 SyncTargetRegistry.ts 体系下的统一接口；设置项的本地存取则由 Setting 模型与各端 KvStore 承担。设置同步要做的，本质上就是把当前仅存于本地的 setting 数据纳入同步器的实体同步流程，KvStore/Setting模型（如 PluginAssetsLoader.ts 中对Setting.value('pluginAssetDir')的使用）是理解这一层的关键入口。

六、文档体系类提案

提案 3：重构项目文档（Refactor the project documentation）

背景：当时的帮助文档主要是一个巨大的 README.md，外加/readme目录下若干较小的 Markdown 文件，再由脚本构建为 HTML 网站。改进方向是：把主 README 拆分成更小的章节、建立重新组织帮助主题的新菜单、并相应更新构建脚本。

文档特别强调该项目的研究属性：很大一部分工作是调研其他项目如何组织文档，提出适合 Joplin 的方案，并与导师和用户讨论。申请者需要主动性强，自己提出文档结构方案——哪些章节与子章节、如何拆分现有 README 等。尽管偏研究，它仍然是技术项目：需要处理 TypeScript、Markdown、HTML 与 CSS（以及任何可能用到的技术）来构建新文档系统。

预期成果：一套全新文档，附带完整的构建脚本与 CI 集成。难度：High。所需技能：TypeScript、JavaScript、CSS、HTML、Markdown 渲染。预估工时：350 小时。导师：Daeraxa、Laurent。

仓库印证：这一提案是 14 个选题中在仓库里"成果痕迹"最明显的之一——packages/doc-builder 即其落地产物，采用 Docusaurus 构建：

• docusaurus.config.js 中docs.path指向help（对应仓库readme/目录），blog.path指向news，并启用 mermaid、lunr 全文搜索、sitemap 与 en/fr/de 三语国际化；
• editUrl直接把编辑链接拼回仓库readme/下的对应路径，实现了"文档即仓库源码"的闭环；
• @docusaurus/plugin-client-redirects中约 30 条旧路径重定向规则（/help/apps/*→/*、/help/about/*→/*、/help/api→/api/*、/help/faq→/faq等），正是"拆分旧 README 后保持旧 URL 不失效"的直接证据；
• 内容侧，readme/apps/、readme/api/、readme/dev/、readme/news/等目录（含 40+ 篇应用文档与 103 篇新闻条目）已经完成了"由巨 README 拆分为主题化小文件"的重构，sidebars.js 与_category_.yml负责菜单组织。

本文所在的 GSoC 文档本身（readme/dev/gsoc/）也遵循了这一按年份/主题拆分的结构。

七、14 个提案速览表

八、配套规则与参与路径

GSoC 2022 的提案文档之外，同目录下的 pull_request_guidelines.md 规定了当年贡献的硬性约束，摘要如下（完整规则以该文件为准）：

• 只处理已被管理员 triage 的 issue（带 high/medium/enhancement 等标签）；
• 每位贡献者同一时间只能有一个 pull request，合并后才能开下一个；
• 所有 PR 必须带单元测试（确实无法测试的情况需先沟通）；
• 不接受 WIP 状态的 PR；借用他人代码必须披露；
• 不要 force push，修订以追加 commit 形式提交；
• 不要 @mention 导师催审。

对于想沿这些选题方向参与 Joplin 开发的读者，文档给出的标准路径是：先读构建文档 BUILD.md 把应用跑起来 → 在论坛注册并与潜在导师建立联系 → 对选定选题的技术栈做深入调研 → 再按当年的提案流程提交项目提案。从当前仓库的模块分布看，14 个提案中至少插件打包（default-plugins）、PDF 查看器（pdf-viewer）、桌面集成测试（integration-tests）、文档体系（doc-builder）四个方向已沉淀为可运行的独立包，这正是把"提案"转化为"仓库代码"的最直观样本——每个方向的源码与测试都构成了一份可继续深挖的实现参考。

【免费下载链接】joplinJoplin - the privacy-focused note taking app with sync capabilities for Windows, macOS, Linux, Android and iOS.项目地址: https://gitcode.com/GitHub_Trending/jo/joplin