尧图网页设计 
TREK 项目贡献指南从分支策略到 PR 合入的完整开发者流程【免费下载链接】TREKA self-hosted travel/trip planner with real-time collaboration, interactive maps, PWA support, SSO, budgets, packing lists, and more.项目地址: https://gitcode.com/GitHub_Trending/nomad22/TREKTREK 是一个采用 TypeScript 全栈 monorepo 架构的自托管旅行行程规划器实时协作、交互式地图、PWA、SSO、预算与打包清单等。本文基于仓库 wiki/Contributing.md 整理出一套完整的贡献者操作手册从动笔写代码之前先做什么到PR 如何通过评审并合入 dev 分支并交叉印证了仓库内 .github/workflows/ 的自动化分支强制、CI 测试流水线以及 .github/PULL_REQUEST_TEMPLATE.md 等实现细节。读完本文你将掌握 TREK 的协作约定、本地开发环境搭建、PR 提交与规避被关闭风险的全部实操要点。动笔之前贡献的前置流程TREK 对 PR 采用先讨论、后编码的严格协作模式这一流程写在 wiki/Contributing.md 的开篇也是仓库 CI 自动化见下文分支强制部分之外最重要的软约束。1. 先在 Discord 中讨论方案在编写任何代码之前先在项目维护的 Discord 服务器#github-pr频道中提出你的想法维护者会告知该 PR 是否被需要并给出方向性指导未经事先讨论和批准的 PR 将被直接关闭。这条规则不是建议而是仓库自动化之外由维护者执行的硬性纪律其背后是避免辛苦写完却无人需要的浪费。2. 检查既有 Issues开始工作前先搜索 open 状态的 issue 或讨论确认你要解决的问题是否已有人在做是否已有相关讨论或半成品方案是否存在可以承接的现成 issue。3. 目标分支必须是dev所有 PR 必须面向dev分支提交不能直接面向main唯一例外只修改wiki/目录下文件的 PR 可以面向任意分支。这条规则的执行细节见下文分支策略的自动化强制一节仓库用 GitHub Actions 保证了它的落地。4. 一个 PR 只做一件事保持 PR 聚焦于单一变更不要把无关的修复捆绑在一起提交。这一要求与仓库 PR 模板中的 Type of Change 选项Bug fix / New feature / Breaking change / Documentation update一一对应。仓库结构速览monorepo 三工作区理解贡献流程前先认识代码库的组织方式。仓库根目录 package.json 声明了 npm workspaces{ name: trek/root, workspaces: [client, server, shared] }client/React 18 Vite 前端Zustand 状态管理、Leaflet 地图、Tailwind CSS依赖见 client/package.jsonserver/Express better-sqlite3 后端含 WebSocket 实时通信、认证、插件系统依赖见 server/package.jsonshared/前后端共享的 Zod API 契约与 i18n 翻译层是单一事实来源见 shared/package.json。这种结构决定了贡献时的影响范围评估改一处 API 契约往往需要同时关注 shared、server、client 三端的类型与测试。本地开发环境搭建wiki/Contributing.md 将完整搭建指南指向 wiki/Development-environment.md下面按该文档展开实际操作步骤。前置要求Node.js 22npmGit一个 GitHub 账号1. Fork 并克隆仓库在 TREK 仓库主页点击Fork创建自己的副本然后克隆到本地注意检出dev分支# 克隆你的 fork检出 dev 分支 git clone -b dev gitgithub.com:your-username/TREK.git cd TREK2. 配置 Git Remotes将原始仓库添加为upstream以便拉取后续更新git remote add upstream gitgithub.com:liketrek/TREK.git此后你将拥有两个 remoteRemoteURL用途origingitgithub.com:your-username/TREK.git你的 forkpush 变更到这里upstreamgitgithub.com:liketrek/TREK.git主仓库从这里 pull 更新3. 保持 fork 与上游同步开始任何工作前确保本地dev分支与 upstream 同步git fetch upstream git rebase upstream/dev # 或: git merge upstream/dev4. 创建功能分支基于dev创建专用分支隔离你的变更、便于评审git checkout -b fix/my-changes origin/dev分支命名约定feat/short-description—— 新功能fix/short-description—— 缺陷修复chore/short-description—— 维护性工作。5. 安装依赖仓库是 npm workspace monorepo在根目录一条命令安装全部npm ci6. 可选KItinerary预订导入预订确认导入功能依赖 KDE KItinerary 解析旅行文档。服务器不带它也能运行但导入端点将不可用。Linux 安装sudo apt-get install -y libkitinerary-bin环境变量写入本地.env或在启动服务器前导出# 必填extractor 二进制路径 KITINERARY_EXTRACTOR_PATH/usr/local/bin/kitinerary-extractor # 防止 Qt 在无头/服务器环境下探测显示器 QT_QPA_PLATFORMoffscreen # KDE 缓存目录避免写入 $HOME XDG_CACHE_HOME/tmp/kf6-cache若二进制安装在其他位置可覆盖KITINERARY_EXTRACTOR_PATH。7. 常用脚本根目录/以下命令跨所有 workspace 执行是推荐的工作方式来自根 package.json命令说明npm run dev先构建 shared再通过concurrently同时启动 sharedwatch、server、clientnpm run build按 shared → server → client 顺序构建npm test依次运行 shared、server、client 的测试npm run test:cov生成 server 与 client 的覆盖率报告npm run test:e2e运行端到端测试servernpm run lint对三个 workspace 执行 lintnpm run format/npm run format:check全工作区格式化 / 校验格式Shared/sharedtrek/shared是前后端共享代码的单一事实来源——包含定义 API 契约的 Zod schema请求/响应形状、通用原语、分页和 i18n 翻译层每种语言的关键字与类型。两端的 workspace 都从它导入因此 schema 与翻译的变更可一处修改、两端生效。提示在此包中运行npm run i18n:parity或i18n:parity:strict可验证每个 locale 暴露相同的翻译键——CI 的 parity 门禁运行的是 strict 变体。常用命令npm run buildtsup 编译、npm run build:watch、npm test、npm run test:watch、npm run typecheck、npm run i18n:parity、npm run i18n:parity:strict、npm run lint、npm run format。Server/server命令说明npm start/npm run start:prod生产模式启动dist/index.jsnpm run devwatch 模式启动npm run build编译 servernpm run typecheck只做类型检查不产出npm test运行全部测试npm run test:unit/test:integration/test:ws/test:e2e按类型拆分运行npm run test:coverage带覆盖率运行npm run lint/npm run format代码检查 / 格式化Client/client命令说明npm run dev启动 Vite 开发服务器npm run build生产构建先运行图标生成脚本scripts/generate-icons.mjsnpm run preview本地预览生产构建npm test/npm run test:unit/test:integration/test:watch/test:coverage测试相关npm run lint/npm run format代码检查 / 格式化npm run e2e运行 Playwright 端到端测试配置见 client/playwright.config.ts8. 提交并推送git add . git commit -m fix: describe your change # 推送到你 fork 的 dev 分支 git push origin fix/my-changes # 或直接在 dev 上工作 git push origin dev然后从 fork 向liketrek/TREK打开 PR目标分支为dev。仅修改wiki/下文件的 PR 不受分支限制约束。PR 规范代码质量与评审标准wiki/Contributing.md 对 PR 提出了明确的质量门槛分四个维度。代码质量要求编写干净、可读、与现有风格一致的代码不做不必要的抽象或过度工程化不添加超出 issue 讨论范围的特性除非逻辑不明显否则不加注释不为不可能发生的场景添加错误处理。评审者看什么是否解决了陈述的问题PR 应对应其要解决的 issue是否最小化无额外重构、无顺手改一下式的变更是否破坏任何东西破坏性变更breaking change不可接受代码是否干净风格一致、无调试日志、无死代码。提交信息Conventional Commits使用约定式提交格式fix(component): short description of what was fixed feat(component): short description of new feature例如仓库根目录版本脚本中使用的version:major、version:patch等约定见 package.json 的scripts同样体现了语义化版本与提交约定的配合。PR 描述遵循模板PR 描述须遵循默认模板 .github/PULL_REQUEST_TEMPLATE.md其包含四部分Description这个 PR 做了什么、为什么Related Issue or Discussion项目要求提交 PR 前必须有 issue 或已批准的 feature requestbug 修复填Closes #ISSUE_NUMBER新特性填Addresses discussion #DISCUSSION_NUMBERType of Change单选 Bug fix / New feature / Breaking change / Documentation updateChecklist是否读过贡献指南、分支是否与dev同步、目标分支是否为devwiki-only PR 除外、是否本地测试、是否补充/更新测试、是否更新文档。哪些情况会导致 PR 被关闭wiki/Contributing.md 明确列出以下 PR 将被关闭未经#github-pr频道讨论和批准的 PR增加不必要复杂度的 PR文档中的例子在已有 undo 功能时再加一个 redo 按钮包含破坏性变更的 PR跨无关文件改变代码风格或格式的 PR无正当理由新增依赖的 PR。分支策略的自动化强制CI 如何落地必须 target devPR 必须面向 dev并非只靠约定仓库用两个 GitHub Actions 工作流将其自动化1. .github/workflows/enforce-target-branch.yml在 PR 打开/重开/编辑/同步时触发pull_request_target核心逻辑若 PR 带有bypass-branch-check标签跳过全部强制供维护者使用分页拉取 PR 的全部变更文件若所有文件都以wiki/开头判定为 wiki-only PR跳过强制并清除已有wrong-base-branch标签若 base 不是main视为已修正移除标签放行若 base 是main检查提交者权限admin/write权限者可放行否则打上wrong-base-branch标签红色d73a4a并留言说明PR 面向 main必须改投 dev24 小时内不修正将被自动关闭同时让检查失败。2. .github/workflows/close-stale-wrong-branch.yml每 6 小时cron: 0 */6 * * *扫描一次对仍带wrong-base-branch标签且创建超过 24 小时的 PR若已改为非 main 分支则移除标签放行否则留言PR 已因 24 小时内未将 base 改为 dev 被自动关闭并直接关闭 PR。这两段工作流就是贡献文档中PRs must be opened againstdev与wiki 文件例外两句话的机器实现读源码可以精确看到豁免判定files.every(f f.filename.startsWith(wiki/))与 24 小时宽限期的执行逻辑。CI 测试流水线合入前的质量门禁.github/workflows/test.yml 定义了 PR 到main/dev分支时触发的四个作业覆盖 server/client/shared 变更路径作业内容i18n-parity运行node shared/scripts/i18n-parity.mjs --strict校验所有语言翻译键的一致性shared-contracts对 shared 工作区执行npm ci --workspace shared、typecheck、npm testserver-tests安装依赖后构建 shared 与 servertsc → dist、typecheck、lint、npm run test:coverage并上传覆盖率产物保留 7 天client-tests安装依赖、构建 shared、typecheck、lint、npm run lint:pages页面模式检查、npm run test:coverage并上传覆盖率此外还有 .github/workflows/lint-prettier.yml、.github/workflows/docker.yml 等工作流分别负责格式与镜像构建。这意味着你的 PR 除了满足文档中的代码质量要求还必须在 CI 上通过类型检查、lint、i18n 键 parity、页面模式约定与完整测试套件——提交前先在本地跑一遍npm test根目录会串行跑全部三个 workspace能显著缩短迭代周期。技术栈速览贡献文档给出的技术栈表格如下可与 client/package.json、server/package.json 中的实际依赖相互印证分层技术前端React 18、TypeScript、Zustand、Leaflet、Tailwind CSS、Vite后端Express、TypeScript、better-sqlite3实时WebSocketws数据库SQLiteWAL 模式认证JWTHS256、bcrypt、TOTP MFA、OIDC地图Leaflet react-leaflet、OSRM、Nominatim、CartoDB tilesi18n15 种语言EN、DE、ES、FR、NL、IT、PT-BR、CS、PL、HU、RU、ZH、ZH-TW、AR、ID补充说明文档表格所列的 15 种语言是贡献约定的基线从仓库实际目录 shared/src/i18n/ 看翻译包集合比该列表更广还包含如 ja、ko、sv、tr、vi 等目录且 shared/scripts/i18n-parity.mjs 会强制每种语言暴露相同的翻译键。若你的变更涉及新增翻译文案务必同步补齐所有语言包并通过 parity 检查。另外仓库根目录 package.json 中overrides字段强制统一 React 19react: 19.2.6、react-dom: 19.2.6使测试渲染器与应用共享同一份 react-dom同时默认关闭了 swagger-ui-dist 的 scarf 遥测。若你的改动涉及 React 相关依赖注意遵循这一统一版本策略。贡献者快速自检清单动手之前对照以下清单确认你的 PR 不会被关闭已在 Discord#github-pr频道获得方向性确认已搜索并关联到对应 issue / discussion本地dev已通过git fetch upstream git rebase upstream/dev同步基于最新dev创建了feat/、fix/或chore/前缀的专用分支根目录执行过npm ci改动相关 workspace 的测试、typecheck、lint 全部通过提交信息遵循 Conventional Commits 格式PR 描述按 .github/PULL_REQUEST_TEMPLATE.md 填写完整目标分支为devwiki-only 除外变更最小化无多余重构、无未授权依赖、无破坏性变更、无跨文件风格改动。【免费下载链接】TREKA self-hosted travel/trip planner with real-time collaboration, interactive maps, PWA support, SSO, budgets, packing lists, and more.项目地址: https://gitcode.com/GitHub_Trending/nomad22/TREK创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 TREK 项目贡献指南：从分支策略到 PR 合入的完整开发者流程
TREK 项目贡献指南从分支策略到 PR 合入的完整开发者流程【免费下载链接】TREKA self-hosted travel/trip planner with real-time collaboration, interactive maps, PWA support, SSO, budgets, packing lists, and more.项目地址: https://gitcode.com/GitHub_Trending/nomad22/TREKTREK 是一个采用 TypeScript 全栈 monorepo 架构的自托管旅行行程规划器实时协作、交互式地图、PWA、SSO、预算与打包清单等。本文基于仓库 wiki/Contributing.md 整理出一套完整的贡献者操作手册从动笔写代码之前先做什么到PR 如何通过评审并合入 dev 分支并交叉印证了仓库内 .github/workflows/ 的自动化分支强制、CI 测试流水线以及 .github/PULL_REQUEST_TEMPLATE.md 等实现细节。读完本文你将掌握 TREK 的协作约定、本地开发环境搭建、PR 提交与规避被关闭风险的全部实操要点。动笔之前贡献的前置流程TREK 对 PR 采用先讨论、后编码的严格协作模式这一流程写在 wiki/Contributing.md 的开篇也是仓库 CI 自动化见下文分支强制部分之外最重要的软约束。1. 先在 Discord 中讨论方案在编写任何代码之前先在项目维护的 Discord 服务器#github-pr频道中提出你的想法维护者会告知该 PR 是否被需要并给出方向性指导未经事先讨论和批准的 PR 将被直接关闭。这条规则不是建议而是仓库自动化之外由维护者执行的硬性纪律其背后是避免辛苦写完却无人需要的浪费。2. 检查既有 Issues开始工作前先搜索 open 状态的 issue 或讨论确认你要解决的问题是否已有人在做是否已有相关讨论或半成品方案是否存在可以承接的现成 issue。3. 目标分支必须是dev所有 PR 必须面向dev分支提交不能直接面向main唯一例外只修改wiki/目录下文件的 PR 可以面向任意分支。这条规则的执行细节见下文分支策略的自动化强制一节仓库用 GitHub Actions 保证了它的落地。4. 一个 PR 只做一件事保持 PR 聚焦于单一变更不要把无关的修复捆绑在一起提交。这一要求与仓库 PR 模板中的 Type of Change 选项Bug fix / New feature / Breaking change / Documentation update一一对应。仓库结构速览monorepo 三工作区理解贡献流程前先认识代码库的组织方式。仓库根目录 package.json 声明了 npm workspaces{ name: trek/root, workspaces: [client, server, shared] }client/React 18 Vite 前端Zustand 状态管理、Leaflet 地图、Tailwind CSS依赖见 client/package.jsonserver/Express better-sqlite3 后端含 WebSocket 实时通信、认证、插件系统依赖见 server/package.jsonshared/前后端共享的 Zod API 契约与 i18n 翻译层是单一事实来源见 shared/package.json。这种结构决定了贡献时的影响范围评估改一处 API 契约往往需要同时关注 shared、server、client 三端的类型与测试。本地开发环境搭建wiki/Contributing.md 将完整搭建指南指向 wiki/Development-environment.md下面按该文档展开实际操作步骤。前置要求Node.js 22npmGit一个 GitHub 账号1. Fork 并克隆仓库在 TREK 仓库主页点击Fork创建自己的副本然后克隆到本地注意检出dev分支# 克隆你的 fork检出 dev 分支 git clone -b dev gitgithub.com:your-username/TREK.git cd TREK2. 配置 Git Remotes将原始仓库添加为upstream以便拉取后续更新git remote add upstream gitgithub.com:liketrek/TREK.git此后你将拥有两个 remoteRemoteURL用途origingitgithub.com:your-username/TREK.git你的 forkpush 变更到这里upstreamgitgithub.com:liketrek/TREK.git主仓库从这里 pull 更新3. 保持 fork 与上游同步开始任何工作前确保本地dev分支与 upstream 同步git fetch upstream git rebase upstream/dev # 或: git merge upstream/dev4. 创建功能分支基于dev创建专用分支隔离你的变更、便于评审git checkout -b fix/my-changes origin/dev分支命名约定feat/short-description—— 新功能fix/short-description—— 缺陷修复chore/short-description—— 维护性工作。5. 安装依赖仓库是 npm workspace monorepo在根目录一条命令安装全部npm ci6. 可选KItinerary预订导入预订确认导入功能依赖 KDE KItinerary 解析旅行文档。服务器不带它也能运行但导入端点将不可用。Linux 安装sudo apt-get install -y libkitinerary-bin环境变量写入本地.env或在启动服务器前导出# 必填extractor 二进制路径 KITINERARY_EXTRACTOR_PATH/usr/local/bin/kitinerary-extractor # 防止 Qt 在无头/服务器环境下探测显示器 QT_QPA_PLATFORMoffscreen # KDE 缓存目录避免写入 $HOME XDG_CACHE_HOME/tmp/kf6-cache若二进制安装在其他位置可覆盖KITINERARY_EXTRACTOR_PATH。7. 常用脚本根目录/以下命令跨所有 workspace 执行是推荐的工作方式来自根 package.json命令说明npm run dev先构建 shared再通过concurrently同时启动 sharedwatch、server、clientnpm run build按 shared → server → client 顺序构建npm test依次运行 shared、server、client 的测试npm run test:cov生成 server 与 client 的覆盖率报告npm run test:e2e运行端到端测试servernpm run lint对三个 workspace 执行 lintnpm run format/npm run format:check全工作区格式化 / 校验格式Shared/sharedtrek/shared是前后端共享代码的单一事实来源——包含定义 API 契约的 Zod schema请求/响应形状、通用原语、分页和 i18n 翻译层每种语言的关键字与类型。两端的 workspace 都从它导入因此 schema 与翻译的变更可一处修改、两端生效。提示在此包中运行npm run i18n:parity或i18n:parity:strict可验证每个 locale 暴露相同的翻译键——CI 的 parity 门禁运行的是 strict 变体。常用命令npm run buildtsup 编译、npm run build:watch、npm test、npm run test:watch、npm run typecheck、npm run i18n:parity、npm run i18n:parity:strict、npm run lint、npm run format。Server/server命令说明npm start/npm run start:prod生产模式启动dist/index.jsnpm run devwatch 模式启动npm run build编译 servernpm run typecheck只做类型检查不产出npm test运行全部测试npm run test:unit/test:integration/test:ws/test:e2e按类型拆分运行npm run test:coverage带覆盖率运行npm run lint/npm run format代码检查 / 格式化Client/client命令说明npm run dev启动 Vite 开发服务器npm run build生产构建先运行图标生成脚本scripts/generate-icons.mjsnpm run preview本地预览生产构建npm test/npm run test:unit/test:integration/test:watch/test:coverage测试相关npm run lint/npm run format代码检查 / 格式化npm run e2e运行 Playwright 端到端测试配置见 client/playwright.config.ts8. 提交并推送git add . git commit -m fix: describe your change # 推送到你 fork 的 dev 分支 git push origin fix/my-changes # 或直接在 dev 上工作 git push origin dev然后从 fork 向liketrek/TREK打开 PR目标分支为dev。仅修改wiki/下文件的 PR 不受分支限制约束。PR 规范代码质量与评审标准wiki/Contributing.md 对 PR 提出了明确的质量门槛分四个维度。代码质量要求编写干净、可读、与现有风格一致的代码不做不必要的抽象或过度工程化不添加超出 issue 讨论范围的特性除非逻辑不明显否则不加注释不为不可能发生的场景添加错误处理。评审者看什么是否解决了陈述的问题PR 应对应其要解决的 issue是否最小化无额外重构、无顺手改一下式的变更是否破坏任何东西破坏性变更breaking change不可接受代码是否干净风格一致、无调试日志、无死代码。提交信息Conventional Commits使用约定式提交格式fix(component): short description of what was fixed feat(component): short description of new feature例如仓库根目录版本脚本中使用的version:major、version:patch等约定见 package.json 的scripts同样体现了语义化版本与提交约定的配合。PR 描述遵循模板PR 描述须遵循默认模板 .github/PULL_REQUEST_TEMPLATE.md其包含四部分Description这个 PR 做了什么、为什么Related Issue or Discussion项目要求提交 PR 前必须有 issue 或已批准的 feature requestbug 修复填Closes #ISSUE_NUMBER新特性填Addresses discussion #DISCUSSION_NUMBERType of Change单选 Bug fix / New feature / Breaking change / Documentation updateChecklist是否读过贡献指南、分支是否与dev同步、目标分支是否为devwiki-only PR 除外、是否本地测试、是否补充/更新测试、是否更新文档。哪些情况会导致 PR 被关闭wiki/Contributing.md 明确列出以下 PR 将被关闭未经#github-pr频道讨论和批准的 PR增加不必要复杂度的 PR文档中的例子在已有 undo 功能时再加一个 redo 按钮包含破坏性变更的 PR跨无关文件改变代码风格或格式的 PR无正当理由新增依赖的 PR。分支策略的自动化强制CI 如何落地必须 target devPR 必须面向 dev并非只靠约定仓库用两个 GitHub Actions 工作流将其自动化1. .github/workflows/enforce-target-branch.yml在 PR 打开/重开/编辑/同步时触发pull_request_target核心逻辑若 PR 带有bypass-branch-check标签跳过全部强制供维护者使用分页拉取 PR 的全部变更文件若所有文件都以wiki/开头判定为 wiki-only PR跳过强制并清除已有wrong-base-branch标签若 base 不是main视为已修正移除标签放行若 base 是main检查提交者权限admin/write权限者可放行否则打上wrong-base-branch标签红色d73a4a并留言说明PR 面向 main必须改投 dev24 小时内不修正将被自动关闭同时让检查失败。2. .github/workflows/close-stale-wrong-branch.yml每 6 小时cron: 0 */6 * * *扫描一次对仍带wrong-base-branch标签且创建超过 24 小时的 PR若已改为非 main 分支则移除标签放行否则留言PR 已因 24 小时内未将 base 改为 dev 被自动关闭并直接关闭 PR。这两段工作流就是贡献文档中PRs must be opened againstdev与wiki 文件例外两句话的机器实现读源码可以精确看到豁免判定files.every(f f.filename.startsWith(wiki/))与 24 小时宽限期的执行逻辑。CI 测试流水线合入前的质量门禁.github/workflows/test.yml 定义了 PR 到main/dev分支时触发的四个作业覆盖 server/client/shared 变更路径作业内容i18n-parity运行node shared/scripts/i18n-parity.mjs --strict校验所有语言翻译键的一致性shared-contracts对 shared 工作区执行npm ci --workspace shared、typecheck、npm testserver-tests安装依赖后构建 shared 与 servertsc → dist、typecheck、lint、npm run test:coverage并上传覆盖率产物保留 7 天client-tests安装依赖、构建 shared、typecheck、lint、npm run lint:pages页面模式检查、npm run test:coverage并上传覆盖率此外还有 .github/workflows/lint-prettier.yml、.github/workflows/docker.yml 等工作流分别负责格式与镜像构建。这意味着你的 PR 除了满足文档中的代码质量要求还必须在 CI 上通过类型检查、lint、i18n 键 parity、页面模式约定与完整测试套件——提交前先在本地跑一遍npm test根目录会串行跑全部三个 workspace能显著缩短迭代周期。技术栈速览贡献文档给出的技术栈表格如下可与 client/package.json、server/package.json 中的实际依赖相互印证分层技术前端React 18、TypeScript、Zustand、Leaflet、Tailwind CSS、Vite后端Express、TypeScript、better-sqlite3实时WebSocketws数据库SQLiteWAL 模式认证JWTHS256、bcrypt、TOTP MFA、OIDC地图Leaflet react-leaflet、OSRM、Nominatim、CartoDB tilesi18n15 种语言EN、DE、ES、FR、NL、IT、PT-BR、CS、PL、HU、RU、ZH、ZH-TW、AR、ID补充说明文档表格所列的 15 种语言是贡献约定的基线从仓库实际目录 shared/src/i18n/ 看翻译包集合比该列表更广还包含如 ja、ko、sv、tr、vi 等目录且 shared/scripts/i18n-parity.mjs 会强制每种语言暴露相同的翻译键。若你的变更涉及新增翻译文案务必同步补齐所有语言包并通过 parity 检查。另外仓库根目录 package.json 中overrides字段强制统一 React 19react: 19.2.6、react-dom: 19.2.6使测试渲染器与应用共享同一份 react-dom同时默认关闭了 swagger-ui-dist 的 scarf 遥测。若你的改动涉及 React 相关依赖注意遵循这一统一版本策略。贡献者快速自检清单动手之前对照以下清单确认你的 PR 不会被关闭已在 Discord#github-pr频道获得方向性确认已搜索并关联到对应 issue / discussion本地dev已通过git fetch upstream git rebase upstream/dev同步基于最新dev创建了feat/、fix/或chore/前缀的专用分支根目录执行过npm ci改动相关 workspace 的测试、typecheck、lint 全部通过提交信息遵循 Conventional Commits 格式PR 描述按 .github/PULL_REQUEST_TEMPLATE.md 填写完整目标分支为devwiki-only 除外变更最小化无多余重构、无未授权依赖、无破坏性变更、无跨文件风格改动。【免费下载链接】TREKA self-hosted travel/trip planner with real-time collaboration, interactive maps, PWA support, SSO, budgets, packing lists, and more.项目地址: https://gitcode.com/GitHub_Trending/nomad22/TREK创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考