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/joplinJoplin 在 2022 年第三次参与 Google Summer of Codereadme/dev/gsoc/gsoc2022/ideas.md收录了当年官方发布的 14 个项目提案ideas每个提案都包含背景描述、预期成果、难度、所需技能、导师与预估工时。本文完整解读这 14 个选题及其技术要点并结合当前 Joplin 仓库中已存在的对应模块插件构建体系、PDF 查看器、桌面集成测试、文档构建器等逐一印证这些提案在源码中的落地形态帮助开发者评估选题、理解实现路径也为想参与 Joplin 贡献的申请者提供一份可检索的参考。一、背景2022 年 GSoC 的主题与两条主线2022 是 Joplin 第三年参与 Google Summer of CodeGSoC。当年的两大主题方向是移动端与平板开发Mobile and tablet development——改进 iOS 与 Android 上的移动/平板应用体验插件与外部应用Plugin and external apps——利用 Joplin API 构建插件和外部应用同时欢迎申请者提出自己的原创想法。提案文档明确强调这 14 个提案本身就是proposal性质的开放选题团队公开欢迎全新的创意。如果有列表之外的想法官方建议的做法是尽早与导师取得联系确认项目现实可行且落在 Joplin 的项目范围内。对候选贡献者的关键提醒文档在 Information for Contributors 一节给出的建议值得所有开源申请者注意这些想法由开发者和用户共同贡献有时表述模糊或不完整。基于某个想法提交 GSoC 提案前强烈建议先主动联系开发者弄清楚该选题的具体细节。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精确到清单中锁定的 commitcheckout 失败会先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-xStorage 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 个提案速览表#项目主题方向难度工时核心技能1移动端插件系统插件High350hTypeScript, React Native2无缝桌面应用更新桌面Medium175hTypeScript, React, Electron/electron-builder3重构项目文档文档High350hTS/JS, CSS, HTML, Markdown 渲染4桌面端内置默认插件插件High350hTS/JS, Electron, GitHub Actions5移动端 Beta 编辑器工具栏编辑器High350hTS/JS, React Native, Hooks, CodeMirror 66改进富文本编辑器集成编辑器High175hTS/JS, CSS/HTML, TinyMCE7改进 PDF 导出桌面/CLIMedium350hTS, JS8替换内置 PDF 渲染器桌面Medium350hTS, JS9Android 重建文件系统同步移动/同步High175hAndroid, Java/Kotlin, TS10平板布局移动High350hReact, TS, CSS11插件搜索与可发现性插件Medium350hTS, CSS, GitHub Actions12邮件插件插件Medium350hTS, JS13桌面应用集成测试桌面High350hTS, JS, Electron14客户端设置同步同步High350hTS, JS八、配套规则与参与路径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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考