我把 VS Code 里看依赖版本的插件，做了一个更快的版本
我把 VS Code 里看依赖版本的插件，做了一个更快的版本
平时写 Node.js 项目时，我经常会在package.json里看看依赖有没有更新。
之前我一直在用Version Lens这类插件，它的体验本身是不错的：打开package.json，就能直接在编辑器里看到可更新的版本，点一下还能直接改掉，不用来回切网页，也不用手敲命令。
但我自己用久了之后，还是有两个比较明显的感受：
- 检查最新版本时，有时候会卡一下
- 点击更新某个依赖时，界面有时会抖，甚至会有一点“整页刷新”的感觉
所以后来我干脆自己做了一个更小、更专注的版本，名字就叫：
Version Lens Fast
它现在只做一件事：
服务好package.json里的依赖版本查看和更新。
不追求一上来支持很多生态，而是先把最常用的这个场景做好。
这个插件解决了什么问题
它的目标其实很简单：
- 在
package.json里直接显示可以更新到哪些版本 - 支持单个依赖快速更新
- 支持批量更新
latest / major / minor / patch - 尽量让刷新是“轻量的、增量的”，而不是每次都整份文件重新来一遍
如果你平时主要就是做前端、Node.js 或全栈项目，这种需求其实非常高频。
很多时候我们不是不知道要升级依赖，而是：
- 不想切到 npm 网站去看
- 不想打开终端跑一堆命令
- 不想在几十个依赖里手动对比版本
把这些信息直接放回package.json旁边，其实是最顺手的。
为什么我没有直接在原插件上改
原版插件做得很完整，支持的生态也很多，这是它的价值。
但“支持很多语言和包管理器”这件事，本身就意味着更多的：
- 解析逻辑
- provider 分发
- 网络请求路径
- 刷新状态管理
如果我的主要目标是：
把package.json这个单点场景做快、做顺
那一个更直接的做法，其实不是继续往“大而全”上走，而是反过来：
先做小，先做窄，先做一个足够好用的版本。
所以这个插件目前就只支持：
package.json- npm registry 风格的包元数据查询
其他 manifest 的扩展点是留好的，但暂时不实现。
我是怎么让它变快一点的
这里其实没有什么特别“神奇”的优化，主要就是几个比较朴素但有效的原则。
1. 先返回本地结果，再后台刷新
一个最影响体感的点是：
不要让编辑器等网络。
所以这个插件的做法是：
- 先从当前文档解析依赖
- 如果有缓存，就先把缓存结果显示出来
- 然后再在后台悄悄刷新
- 刷新完之后增量合并结果
这样做的好处是，重新打开显示时不会“空一会儿”，而是先有东西，再变新。
2. 只刷新变动的依赖，不整份重算
一开始最容易写出来的实现，是这样的：
- 文件改了
- 那就整份
package.json重新解析 - 然后所有依赖重新请求一遍
这样逻辑最简单，但体验一般。
后来我把它改成了增量方式：
- 如果只改了一个依赖
- 就只把这个依赖标记为 dirty
- 后台只刷新这一项
- 其他依赖的状态保持不动
这样你点击更新某个包时，就不会看到整页都跟着重新“检查”。
3. 更新文本时，只改那一小段 range
另一个非常影响观感的问题是“页面乱跳”。
原因也不复杂：
如果每次更新一个依赖，都直接把整个package.json文本整体替换掉，VS Code 往往会重新计算滚动位置、CodeLens 布局，用户看到的效果就是：
- 光标位置有点跳
- 页面上下抖一下
- 有时会像整页刷新
所以后面我改成了：
直接定位到依赖 version 对应的文本 range，只替换那一小段。
比如把：
"react":"^18.2.0"只替换成：
"react":"^19.0.0"而不是整份文件全量重写。
这个改动不复杂，但对体验影响很明显。
4. 做缓存，但缓存也要有时效
依赖版本信息本质上是远端数据，所以缓存很重要。
这里用了两个简单策略：
- 内存缓存
- in-flight 请求去重
也就是说：
- 同一个包，短时间内不要重复请求
- 如果同一时刻有多个地方要查同一个包，只发一次请求
但缓存也不能无限久，所以我保留了 TTL。
这样可以兼顾两件事：
- 日常操作时足够快
- 过一段时间还是会拿到较新的结果
功能上，我保留了哪些比较实用的东西
虽然这个插件范围缩小了，但常用功能我尽量还是保留了：
Toggle release versionsToggle prerelease versionsClear cacheUpdate dependencies to latestUpdate dependencies (major-only)Update dependencies (minor-only)Update dependencies (patch-only)Sort dependencies alphabetically
我还特地把标题栏按钮收得比较简单：
- 右上角只留一个主切换按钮
- 其他不那么高频的动作走命令面板
这样不会让编辑器工具栏显得太满。
这个插件适合谁
我觉得比较适合这几类人：
- 平时主要维护前端或 Node.js 项目
- 经常直接在
package.json里看依赖 - 希望“看版本”和“改版本”都尽量在编辑器里完成
- 更在意响应速度，而不是一开始就支持很多生态
如果你需要的是：
- 多语言包管理支持
- 私有 registry 授权
- 漏洞诊断
- 更完整的生态覆盖
那原版思路还是有它的价值。
但如果你的日常场景就是package.json，那一个更专注的实现，反而更合适。
做这个插件时，我自己也复盘了一个很简单的道理
很多“卡”的问题，最后未必需要特别复杂的技术。
更多时候，真正有效的是这些基础动作：
- 不要阻塞主交互
- 不要全量刷新可以增量处理的东西
- 不要重写整份文本，只改必要范围
- 不要重复请求同一个远端数据
- 不要为了“功能更多”把常见路径做重了
这些原则在插件开发里适用，在 Web 开发里其实也一样适用。
插件地址
你可以直接在 VS Code 商店里搜索：
Version Lens Fast
如果你平时就习惯在package.json里处理依赖版本，它应该会比较顺手。