Conversation
There was a problem hiding this comment.
Pull Request Overview
本PR实现了统一的脚本更新提醒机制，解决了以前定时检查更新时会一次性弹出多个页面的困扰问题。新机制将检查和显示分离，检查结果先保存到内存中，等用户访问相关网站时再弹出通知，用户还可以忽略特定版本的更新。
核心改进:
- 修改了定时检查间隔为首次5分钟后，之后每30分钟检查一次
- 新增批量更新页面和URL监控机制，实现智能的更新提醒
- 集成代码相似度分析，帮助用户判断更新幅度
Reviewed Changes
Copilot reviewed 22 out of 23 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
| src/pages/store/features/script.ts | 添加批量更新相关的API函数 |
| src/pages/popup/App.tsx | 修改检查更新菜单行为，调用新的批量更新页面 |
| src/pages/options/routes/script/ScriptEditor.tsx | 保存脚本时清空ignoreVersion字段 |
| src/pages/install/App.tsx | 安装脚本时清空ignoreVersion字段 |
| src/pages/import/App.tsx | 导入脚本时清空ignoreVersion字段 |
| src/pages/batchupdate/ | 新增批量更新页面，支持分组显示和操作 |
| src/locales/ | 添加批量更新页面的多语言支持 |
| src/app/service/service_worker/url_monitor.ts | 新增URL监控模块，检测用户域名切换 |
| src/app/service/service_worker/types.ts | 定义批量更新相关的类型定义 |
| src/app/service/service_worker/script_update_check.ts | 新增脚本更新检查核心逻辑类 |
| src/app/service/service_worker/script.ts | 重构脚本更新检查逻辑，支持批量处理 |
| src/app/service/service_worker/runtime.ts | 运行时记录脚本相关网站信息 |
| src/app/service/service_worker/index.ts | 集成URL监控和更新提醒逻辑 |
| src/app/service/service_worker/client.ts | 添加批量更新相关的客户端API |
| src/app/repo/scripts.ts | 扩展脚本数据结构，支持ignoreVersion和站点信息 |
| rspack.config.ts | 添加批量更新页面的构建配置 |
| package.json | 添加string-similarity-js依赖 |
Files not reviewed (1)
- pnpm-lock.yaml: Language not supported
src/app/repo/scripts.ts
Outdated
| export class ScriptSiteDAO extends Repo<ScriptSite> { | ||
| constructor() { | ||
| super("scriptSite"); | ||
| } | ||
|
|
||
| getSites() { | ||
| return this.get("sites"); | ||
| } | ||
|
|
||
| public saveSites(val: ScriptSite) { | ||
| return super._save("sites", val); | ||
| } | ||
| } |
There was a problem hiding this comment.
每一个脚本适用一个网站就记录一次，是不是会太多了，如果有很多脚本，随着时间推移将是一个很恐怖的数量（另外关闭的脚本没有记录，也许这算一个feature？），我觉得根据getPageScriptMatchingResultByUrl来判断也可以，如果存在通配，直接显示在 此网站可用更新 中
There was a problem hiding this comment.
有想过记录问题，但对比储存起来的代码库，容量很小吧
一个脚本只是50个域名。
1000个脚本都只是 1000 * 50 个域名 （一個腳本最多儲 50 個網域）
假设一个域名是 www.facebook.com 这么长
16bytes * 1000 * 50 = 800kb
不想用太多 pattern 分析
直接存起来就好了
不然1000个脚本，除了执行还有更新每一次都要分析来分析去
| // 检查是否符合 | ||
| // if (script.checktime + checkCycle * 1000 > now) { | ||
| // return false; | ||
| // } |
There was a problem hiding this comment.
改良後的設計不用這個檢查
定時有定時的 chrome.Alarm
手動的就手動
There was a problem hiding this comment.
这里不是有一个上次检查更新时间吗？之前的检查更新是针对每个脚本的，现在按照配置的检查更新频率检查所有的呢？
There was a problem hiding this comment.
只有手动一个一个点检查才会有不一样吧
现在这个版面只考虑全部检查的时间
（定时检查全部/手动检查全部）
不会因为单一脚本上次检查了就不理它吧
这个版面是显示全部的更新有无
当然如果你有什么想法都可以提出来再改进一下
那配置检查更新频率失去了意义
现在是的。
可以用来改 chrome.Alarm 的时间相隔吧
透过 systemConfig subscribe之类 重新注册chrome.Alarm
不论是单一检查，全部检查，手动还是定时
现在还是有在每个脚本中储存 最后检查时间
只是用来显示用？没实际作用
倒过来 全部检查的时间间隔可以改一下
30分钟 或者 3小时 也可以。 听过一个说法是 npm包的话 1小时 。1小时内刚发布的避免bug 别使用。 UserScript同理要给时间作者改改脚本。
再改善的话，例如30分钟检查一次，3次都是同样的新版本 （作者没有立即修bug -> 没有bug)就可以升级
There was a problem hiding this comment.
这样也可以，暂时没想到其它的方案，这样的话，需要改一下或者删除这个配置了
现在还是有在每个脚本中储存 最后检查时间
之前会根据这个时间去查询符合检查周期的脚本
听过一个说法是 npm包的话 1小时
这个不清楚，不过我认为如果你更新了一个错误的版本，在已经发布了的前提下，正确的做法应该是再加一个小版本号进行升级，我觉得我们不用考虑这个操作，增加复杂度了，而且作者也可能在30分钟后才修好更新
|
用起来没问题，先合并了，其它问题后续再调整 👍 |
概述
过住定时检查更新时，会一口气弹出十多个Tab
因此，很困扰。
现在检查和表示是独立行为。
定时检查后会先保存，等到用户打开相关网站时，才跳出来。
用户可以忽略某一版本，不再跳出来。
如用户没有操作，前台时8秒后自动关掉
用户也可以在菜单的检查更新中打开页面。
close #569
变更内容
（5分钟是避免刚打开时过多网络操作。30分钟是避免开发人员推错了更新，给多一点时间 -- 这个日后会再检讨修改）
slienceUpdate
如果是定时检查，
opts.checkType会是 "system"this.systemConfig.getSilenceUpdateScript()也是 true 的话会自动 静默更新
如果是人工检查更新，则不会 静默更新 （
opts.checkType是 user）会显示在画面。
（当系统定时更新，因为 静默更新， 所以画面上的内容会更新，静默更新的脚本会不再出现）
（如果该更新版本被用户忽略，静默更新会跳过此更新）
相似度 （参考用）
根据脚本的改动和数字的对比，划出了 绿蓝红
绿都可以安心更新，功能上没大变动
蓝是有明显改动
红都是大改动。当然可能是写法大改动之类，不一定有功能改变
GREEN
（红色行主要都是删空行删注释。因此相似度为高）
BLUE
（代码结构大致没改动，因此蓝色）
RED
截图