Self-hosted LiveSync 贡献指南:从环境搭建、代码验证到翻译与发布的全流程实战 数据同步【免费下载链接】obsidian-livesync项目地址https://gitcode.com/gh_mirrors/ob/obsidian-livesync点击查看免费下载本篇指南基于 obsidian-livesync 仓库的 CONTRIBUTING.md 与 devs.md 编写系统讲解如何为 Self-hosted LiveSync一个使用 CouchDB、MinIO/S3 或 WebRTC P2P 在设备间同步 Obsidian 库的插件提交高质量贡献。读完本文你将掌握完整的开发环境搭建流程、提交 PR 前必须通过的验证命令、仓库的文档与 UI 文本风格约定、翻译i18n贡献的完整工作流以及涉及vrtmrz/livesync-commonlib共享库时如何正确变更依赖边界。项目与贡献概览Self-hosted LiveSync 是一个 Obsidian 插件核心能力是把 Vault笔记库的变更即时同步到其他设备后端可选用自托管的 CouchDB、S3 兼容对象存储如 MinIO或无需中心存储的 WebRTC P2P 模式。代码库采用模块化架构技术栈为 TypeScript、Svelte 与 PouchDB详见 devs.md。项目欢迎各类贡献包括Bug 报告、功能请求、文档改进、翻译以及 Pull Request。所有贡献都需要遵守以下三个基本要求提交 PR 前在本地跑通验证脚本文档与用户可见文案遵循统一的写作风格涉及共享同步逻辑的变更必须通过livesync-commonlib仓库走独立的贡献流程。开发环境搭建首次搭建按 CONTRIBUTING.md 给出的三个步骤即可完成从零到可构建的开发环境git clone https://github.com/vrtmrz/obsidian-livesync npm ci npm run build说明npm ci严格按照package-lock.json安装依赖而不是像npm install那样可能改写锁文件npm run build使用 esbuild 执行生产构建对应 package.json 中的esbuild.config.mjs production构建产物main.js即插件本体可以安装进 Obsidian 的 Vault 中进行调试。切换分支时的注意事项仓库存在补丁分支等历史分支。切换分支时如果锁文件发生变化必须重新执行依赖安装否则可能出现依赖与代码不匹配导致的诡异错误git checkout 0.25.70-patch1 # tag 或分支名 npm ci npm run build依赖安装的双路径验证仓库同时面向「普通开发者」与「社区目录审查Community Review」两种安装路径两者使用的 npm 版本不同。修改package.json、工作区清单或package-lock.json之后需要同时验证两条安装路径详见 devs.mdnpm ci --ignore-scripts npx --yes npm10.9.2 ci --ignore-scripts其中npm10.9.2是当前项目侧对 Community Review 安装路径的兼容性检查版本。如果 Community Review 报告大量外部包的类型错误先确认依赖是否安装成功——安装失败会让所有未解析的外部类型都表现为下游不安全类型unsafe-type问题此时不要急于修改源码导入或 lint 规则。提交 PR 前的代码验证体系CONTRIBUTING.md 明确要求提交 Pull Request 之前必须在本地运行验证脚本确保没有语法、类型或 lint 错误。类型检查与 lintnpm run check从 package.json 的check脚本定义可以看到它实际串联了六项检查tsc-check主工程 TypeScript 类型检查tsc --noEmittsc-check:apps对src/apps/browser、src/apps/cli、src/apps/webapp、src/apps/webpeer五个应用子工程分别做类型检查lintESLint 检查src目录使用--cache增量缓存lint:community -- --quiet应用社区目录阻塞规则只输出错误级别问题lint:community:tools对_tools目录的工具脚本执行零警告上限的检查svelte-checkSvelte 组件类型检查--fail-on-warnings。此外还有check:compatibility在precheck:compatibility中被调用它通过 utils/check-compatibility.js 验证构建产物main.js是否兼容 iOS 15 级别的运行环境。如果只想查看 Community Review 的非阻塞建议可单独运行npm run lint:community单元测试npm run test:unit单元测试使用 Vitest配置见 vitest.config.unit.ts。仓库约定单元测试文件命名为*.unit.spec.ts与被测实现放在同一目录例如ChunkFetcher.unit.spec.ts在 Node.js 中运行排除 harness 与集成测试。文档契约检查Inspect Troubleshooting当修改troubleshooting或recovery相关文档时必须运行只读的检查器npm run inspect:troubleshooting该命令对应 _tools/inspect-troubleshooting-docs.ts它执行三类契约校验并输出 JSON 结果包含ok、checkedFiles、checkedLocalReferences、errors四个字段当契约过期时以非零退出码结束current-label 检查校验 docs/troubleshooting.md 是否仍包含 src/common/messagesJson/en.json 中定义的当前 UI 文案如TweakMismatchResolve.Action.UseConfigured等键retired-label 检查确保文档中没有残留已退役的旧文案如Update with mine、Use configuredlocal-reference 检查对docs/troubleshooting.md、docs/recovery.md、docs/tips/p2p-sync-tips.md三份指南中的所有本地 Markdown 链接做存在性校验任何指向不存在文件的链接都会被记录为错误。因此更新故障排查文档时务必同步核对它引用的 UI 文案与本地文件路径保证文档契约持续有效。E2E 测试与 CI如果具备合适的 Linux Docker 环境强烈建议运行 CLI 端到端测试详见 devs.md 与 src/apps/cli/testdeno。若本地无法运行 E2E请在 PR 描述中明确写明「Please run CI tests」请求 CI 代为执行。仓库的测试体系呈金字塔结构可按变更范围选择最窄的测试命令测试类型命令说明单元测试npm run test:unitVitestNode.js 环境覆盖率npm run test:unit:coverage单元测试 覆盖率报告集成测试npm run test:integration连接真实 CouchDB 实例的*.integration.spec.ts自托管工具契约npm run test:setup-toolsDeno 校验 CouchDB / 对象存储 / P2P Setup URI 契约CLI P2P E2Enpm run test:e2e:cli:p2pCompose 中的规范 P2P 验证浏览器应用npm run test:browser-appsWebApp 与 WebPeer 的 Chromium 测试跨应用互操作npm run test:e2e:browser-apps:interopWebApp → WebPeer → CLI 互操作真实 Obsidian E2Enpm run test:e2e:obsidian:local-suite启动真实 Obsidian 的本地套件其中真实 Obsidian E2Etest/e2e-obsidian/用于验证启动序列、Vault 反射、RedFlag 流程、Fast Setup、设置对话框、对象存储回归等依赖 Obsidian 本身的行为。服务类测试通过 Docker 启动 CouchDB 与 MinIOS3作为测试基础设施npm run test:docker-all:start # 启动所有测试服务 npm run test:integration # 运行相关的服务支撑测试套件 npm run test:docker-all:stop # 停止服务注意服务已在运行时启动脚本会失败需要先停止再启动。文档与 UI 文本的风格规范为保证项目一致性贡献文档或用户可见文案时必须遵循 docs/terms.md 与 docs/glossary.md 中确立的写作惯例。CONTRIBUTING.md 给出了六条核心规则拼写Spelling优先使用地区中立的拼写若无中立词则与代码库一致采用英式拼写例如偏好-ise/-isation后缀而非-ize/-ization。但替代拼写不视为错误牛津逗号Oxford Comma列表含三项及以上时使用序列逗号例如settings, snippets, and themes逻辑标点Logical Punctuation标点放在引号之外除非标点本身属于被引用文本例如写dialogue而不是dialogue,禁止缩写No Contractions正文与文档避免缩写写do not而非dont写cannot而非cant肯定表述Affirmative Phrasing面向用户的对话中避免用否定形式提问以降低翻译与解释歧义特定词汇Specific Words文档与用户文案用dialogue源码内才用dialog用户可见文本用连字符形式plug-in仅在配置项或技术语境中用plugin。项目术语的完整定义见 Project glossary其中包含可能不出现在用户界面中的内部开发与设计术语。翻译i18n贡献流程Self-hosted LiveSync 拥有独立的多语言文案目录。详细教程见 docs/adding_translations.md核心流程如下。为已有文案补充翻译编辑src/common/messagesYAML/下人类可读的 YAML 文件仓库提供de、es、fr、he、ja、ko、ru、zh、zh-tw九种语言及默认英文en执行烘焙命令将 YAML 编译为 JSON 与 TypeScript 常量npm run i18n:bakei18n:bake实际串联了三个子步骤见 package.jsoni18n:yaml2json调用 _tools/yaml2json.ts、i18n:bakejson调用 _tools/bakei18n.ts 生成src/common/messages/combinedMessages.prod.ts、i18n:formatPrettier 格式化产物以开发模式构建插件并安装到测试 Vault 中运行检查.obsidian/ls-debug目录下生成的missing-translation-yyyy-mm-dd.jsonl文件把缺失的键补进 YAML 目录再次烘焙并构建在相关流程中确认显示文本与占位符替换正确。提交时必须把编辑过的 YAML 与所有重新生成的 JSON、TypeScript 资源一起提交。在代码中使用翻译代码中通过三个翻译函数消费文案实现在 src/common/translation.ts$msg(dialog.someKey); // 带类型键的翻译支持自动补全与参数替换 $t(Some message); // 直接翻译 $fHello, ${userName}; // Tagged Template Literal 形式的格式化消息其中$msg(key, params)支持${placeholder}形式的运行时参数替换。语言解析逻辑会把 Obsidian 的语言代码映射到目录键例如zh-cn、zh-hans归入zhzh-tw、zh-hant归入zh-tw未匹配时回退到默认英文def。缺失翻译会通过__onMissingTranslations回调上报并写入ls-debug日志。让一条消息变得可翻译当新文案措辞还在打磨阶段时可先加入 src/common/messages/LiveSyncProvisionalMessages.ts获得类型化的英文回退而无需立即更新所有语言。文案稳定后将英文条目从LiveSyncProvisionalMessages.ts移到src/common/messagesYAML/en.yaml并在同一变更中删除临时条目把源码中的字面量替换为$msg()等翻译辅助函数运行npm run i18n:bake并验证受影响的工作流。若新消息属于 Commonlib共享同步逻辑库而非应用本体则应先在 Commonlib 中定义规范英文条目与键类型再在 LiveSync 中补充翻译未翻译的语言自动回退到 Commonlib 的规范英文。Commonlib 变更共享同步逻辑的边界Shared synchronisation behaviour 由vrtmrz/livesync-commonlib包提供当前锁定版本见 package.json 中的vrtmrz/livesync-commonlib依赖。该包是平台无关的同步逻辑层被 CLI、WebApp、WebPeer 与外部工具共享。如果希望修改这个共享库必须遵循独立流程向 livesync-commonlib 仓库提交单独的 PR验证打包packed后的产物回到本仓库更新锁定的依赖版本。两个仓库的边界规则是npm ci只安装锁文件记录的精确产物本仓库不编译 Commonlib 源码、也不提交回退声明fallback declarations。跨越两个仓库的变更必须先产出通过独立包检查的 Commonlib 打包产物在 LiveSync 中安装该精确产物并跑通类型检查、单元测试、应用构建、CLI E2E 及必要的真实 Obsidian E2E发布前再替换为已评审的不可变包版本。许可证声明项目采用 MIT 许可证。根据 CONTRIBUTING.md 的约定提交贡献即表示同意你的贡献以 MIT 许可证授权发布。若计划使用机器翻译引擎生成翻译资源请先确认引擎的服务条款与项目许可证兼容src/common/rosetta.ts 中有同样提醒。小结贡献前检查清单完成一篇贡献前对照以下清单逐项确认✅ 环境npm cinpm run build通过✅ 质量门npm run check零错误类型、lint、Svelte、兼容性✅ 测试npm run test:unit通过涉及远程数据库行为时补充*.integration.spec.ts集成测试✅ 文档契约改动 troubleshooting/recovery 文档后运行npm run inspect:troubleshooting✅ 风格文档与 UI 文案符合拼写、标点、术语规范docs/terms.md✅ 翻译新增文案按 YAML → 烘焙 → 验证流程处理缺失翻译写入ls-debug检查✅ 边界涉及共享逻辑时走 Commonlib 独立 PR不在本仓库塞源码镜像或回退声明✅ 依赖升级依赖后检查构建产物 diff只保留预期变化。遵循以上流程你的 PR 就能顺畅通过 CI 与社区目录审查成为 Self-hosted LiveSync 生态的一部分。赞分享数据同步【免费下载链接】obsidian-livesync项目地址https://gitcode.com/gh_mirrors/ob/obsidian-livesync点击查看免费下载相关推荐cleanlab 开发环境搭建与代码贡献指南从虚拟环境、测试到发布的全流程实战cleanlab 开发环境搭建与代码贡献指南从虚拟环境、测试到发布的全流程实战 导读 本文是面向 cleanlab 贡献者的开发者指南完整梳理了从搭建本地开人工智能机器学习数据清洗数据质检AppImageLauncher开发指南从环境搭建到代码贡献全流程AppImageLauncher开发指南从环境搭建到代码贡献全流程 你是否曾为Linux下AppImage应用的集成管理感到困扰作为开发者你是否想为开源社桌面应用CLICode-Graph-RAG 贡献指南从开发环境搭建、代码规范到 CI/发布全流程实战Code Graph RAG 贡献指南从开发环境搭建、代码规范到 CI/发布全流程实战 本文是 Code Graph RAG 仓库 docs/contribu人工智能RAG知识图谱MCP 服务开发者工具创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考