Feat/about page logging updater - #18
Merged
Merged
Conversation
侧边栏版本号进入关于页；用户可见日志改为带 info/warn/error 的英文短句；接入 GitHub Releases 自动更新。 Co-authored-by: Cursor <cursoragent@cursor.com>
把残留的非英文日志输出改为英文短句，日志级别、占位符、变量与调用位置 全部保持不变： - Rust: commands/paths.rs 三条 eprintln!、engine/mirror_config.rs 两条 log:: - 前端: App.vue、EnvConfigPage.vue、utils/portChecker.ts 共 8 处 console.error - 脚本: sync-php-dockerfile.mjs、sync-version-manifest.mjs 的 CLI 输出与报告头 协议层字符串（sync-version-manifest.mjs 的 reason 字段、throw 的 Error 文案） 与依赖它们的单测断言本轮不动：这些串被 startsWith()/includes() 判定与断言 直接依赖，必须与判定逻辑同批修改，否则 --check/--apply 会误判同步状态。 顺带补齐 scripts/sync-version-manifest.mjs 末尾缺失的换行。 验证: cargo check --all-targets 零警告通过；vite build 成功；vitest 21 文件 221 测试通过；两个脚本实跑冒烟输出英文。vue-tsc 报的 9 个错误经 HEAD 快照 基线对照逐条一致，确认为分支既有问题，与本次改动无关。
emit_progress 的 step 原本是硬编码中文，且被直接渲染在备份/恢复进度面板上—— 中英文界面下各有一半用户看到错误语言。改为后端只发 i18n key、前端 t() 翻译： - Rust: backup_engine / restore_engine 共 17 处 step 改为发 key，并在 emit_progress 上写明契约（step 是 key，不要拼自然语言） - 前端: BackupPage / RestorePage 渲染改 $t(progress.step)，初始态与完成态 也由"传译文"改为"传 key" - i18n: 新增 backup.progress.steps(8 条) 与 restore.progress.steps(9 条)，中英同步 restore.progress 节点原本就已存在（含 title），首版改动误插成了同层重复节点、 把 title 挤掉导致 check:i18n 报悬空引用，已改为折叠进原节点；并用重复 key 扫描器确认两个语言包均无同层重名（JSON.parse 会静默折叠重复 key，不能靠它查）。 顺带修好 restore.progress.title 这个悬空引用——此前会原样渲染成 key 文本。 验证: cargo check --all-targets 零警告；cargo test 146 项全过； check:i18n 510/510 通过；vitest 21 文件 221 测试通过；vite build 成功； 两种 locale 下冒烟确认新 key 均可解析出正确文案。
log:: 宏只走 tracing，不写日志文件——导出日志里会缺这两条，排查时看不到 "为什么用了默认镜像源"。改为 app_log!（同时写文件与控制台），顺带去掉⚠️ /✅：emoji 进日志文件既占空间又不利于 grep。至此 src-tauri/src 内 再无 log:: 宏调用，日志出口统一到 app_log!/ui_log!。 - 新增 use crate::app_log，两条日志改为英文短句，级别与语义不变 验证: cargo fmt --check 通过；cargo clippy --all-targets -D warnings 零警告； cargo test 146 项全过。 注: Cargo.toml 的 log = "0.4" 由此变成未使用的直接依赖，本轮未动—— 需先确认 tauri-plugin-log 是否间接依赖它，避免误删破坏日志桥接。
此前 网络/解析失败、离线无缓存、离线模式 三串散落在五处：throw 的 Error 文案、
offlineNoCache 的 includes 判定、skipped[].reason 构造、fetchFailures 的
startsWith 过滤、以及单测 fixture。它们靠"手抄同一串"保持一致，改一处漏一处
就会让 --check 把「fetch 全挂」误判成「完全同步」并放绿灯——这正是该脚本
最危险的失效模式。
改为导出常量 REASON{NETWORK,OFFLINE_NO_CACHE,PARSE_UNMATCHED} 与
OFFLINE_ERR_PREFIX，五处全部引用同一份定义，单测也从常量构造 fixture，
从此不存在"漏改一处"的可能。
验证: --check --offline 实跑，四个服务全部 fetch 失败时 reason 走
OFFLINE_NO_CACHE 分支、fetchFailures=4、exit 1 阻断生效（未误放行），
Skipped items 段落已全英文；vitest 21 文件 221 测试通过。
返回前端的错误串改为英文短句，占位符、变量与级别保持不变：
backup_engine(11) / backup_manifest(6) / restore_engine(26) /
commands/backup.rs(4) 共 47 处。
同步改掉依赖这些文案的断言：backup_manifest 的
contains("过新"/"过旧"/"无效") 与 restore_engine 的 contains("过新")。
它们校验的是 check_manifest_version 的三态分支，生产文案与断言必须同批改——
只改生产侧的话，测试会因为断言的是"另一套词"而依然全绿，真正坏掉的
"拒绝过新备份包"分支却无人发现。
英文串普遍更长，已跑 cargo fmt 重新排版。
验证: cargo fmt --check 通过；cargo test 146 项全过（含上述三态断言）。
把剩下 11 个文件共 70 处返回前端的错误串改为英文短句：
commands/docker、commands/env_config、commands/mirror、commands/paths、
docker/manager、engine/config_generator、engine/mirror_config、
engine/mirror_config_manager、engine/mirror_manager、engine/version_manifest、
engine/workspace_manager。同步改掉依赖这些文案的断言：
paths 的 contains("无法创建工作区目录")、mirror_manager 的
contains("未找到预设方案") 与 contains("未知的镜像源类别")。
跨端判定必须一起改——前端 EnvConfigPage.formatErrorMessage 原本按
includes('读取'/'写入'/'解析'/'端口') 给错误分类。后端改英文后这些中文分支
全部变成死代码，且新文案 "backup file already exists" 里的 already 会被
includes('read') 命中，误判成"读取失败"。改为按词边界匹配的 hasWord()，
顺带避开 HOST_PORT 命中 port 这类旧误判。
未纳入本批（不是 Err，属 UI 展示文案，需要 i18n 而非单纯英文化）：
mirror_manager 的预设名（阿里云全套/官方默认等）、mirror_config_manager 的
"自定义"、version_manifest 的版本告警后缀、env_config 的文件描述串。
paths.rs 的 reason 字段留给下一个提交走 i18n key。
验证: cargo fmt --check 通过；cargo clippy --all-targets -D warnings 零警告；
cargo test 146 项全过；hasWord 用 8 条真实错误串冒烟（含 already/read 与
HOST_PORT/port 两组反例）全部符合预期；vitest 221 项通过；check:i18n 通过；
vite build 成功。
resolve_workspace 回退时给的 reason 原本是 Rust 里拼好的中文句子，被前端
原样插进 workspace.status.fallback 展示——英文界面下会看到一句中文原因。
只改 eprintln! 治不了这个，因为问题出在"后端产自然语言"。
改为后端只发 i18n key（workspace.reason.configuredMissing，带 {path} 占位），
前端 t(key, { path: info.workspace_path }) 翻译后再插入横幅。日志侧把真实
路径和 key 一起打出来，避免留下一条只剩 key、看不出是哪个目录的日志。
新增中英两条文案；paths.rs 内无断言依赖 reason 内容。
验证: cargo fmt --check 通过；cargo test 146 项全过；check:i18n 通过
（新 key 是动态引用，会被计入"未被源码引用"的提示，属预期）；
vitest 221 项通过；vite build 成功。
上一轮把 mirror_config.rs 最后两条 log:: 迁到 app_log! 后，源码里已无任何 log crate 引用（log:: 宏、use log、extern crate log 全部清空）。Cargo.toml 里的 log = "0.4" 就此变成闲置的直接声明，删掉。 不会破坏日志能力：log 仍由 8 个间接依赖带入（html5ever / markup5ever / selectors / tauri-utils / arboard / bollard / fern / handlebars）， tauri-plugin-log 自身也直接依赖 log + fern。Cargo.lock 只删了 app 依赖清单 里的一行，log 包条目及其 38 处被引用关系原样保留。 tracing 与 tracing-subscriber 经查仍在直接使用，保留： - macros.rs 的 app_log!/ui_log! 展开到 tracing::info!/warn!/error!/debug! - logging.rs 用 tracing_subscriber 的 fmt + EnvFilter 配置 subscriber 验证: cargo tree -i log 确认 app 不再是直接依赖方且 log 仍在树中； cargo clippy --all-targets -D warnings 零警告；cargo fmt --check 通过； cargo test 146 项全过；vitest 221 项通过；vite build 成功。
「环境迁移」页白屏的根因：App.vue 模板里用了 <MigrationPage />，但 script setup 从未 import 该组件。vue-tsc 默认不开 strictTemplates，未解析组件按 any 放行，所以类型检查零报错；生产构建把它编译成 resolveComponent，运行时 解析失败后警告被剥离、子树渲染为空——于是白屏且控制台无任何输出。jsdom 单测全绿也测不到（直接 mount 的组件都能正常渲染，坏的是 App.vue 的解析）。 同批修掉同类的第二个雷：App.vue L425/446 使用 WORKSPACE_CHANGED_EVENT 但同样没 import，onMounted 每次启动都抛 ReferenceError，且 throw 点之后的 updater 检查（f5b3836 引入的自动更新）永远不会执行。补上来自 utils/workspaceEvents 的导入后，工作区切换刷新监听与更新检查同时恢复。 发现手段：用系统 Edge + playwright-core 无头驱动 vite preview 产物， 逐 tab 点击对比渲染结果，点击迁移页零报错但子树不在 DOM——生产环境静默 失败的特征。修复后同法复验：迁移页 h1「环境迁移」「环境备份」与备份选项 面板正常渲染，启动期 ReferenceError 消失。 vue-tsc 错误数 9 → 7（两条 TS2304 消除，其余 7 条为分支既有）； vitest 21 文件 221 项通过；vite build 成功。
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.