我把 VS Code 里看依赖版本的插件，做了一个更快的版本

我把 VS Code 里看依赖版本的插件，做了一个更快的版本

平时写 Node.js 项目时，我经常会在 package.json 里看看依赖有没有更新。

之前我一直在用 Version Lens 这类插件，它的体验本身是不错的：打开 package.json，就能直接在编辑器里看到可更新的版本，点一下还能直接改掉，不用来回切网页，也不用手敲命令。

但我自己用久了之后，还是有两个比较明显的感受：

1. 检查最新版本时，有时候会卡一下
2. 点击更新某个依赖时，界面有时会抖，甚至会有一点“整页刷新”的感觉

所以后来我干脆自己做了一个更小、更专注的版本，名字就叫：

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 versions
• Toggle prerelease versions
• Clear cache
• Update dependencies to latest
• Update 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 里处理依赖版本，它应该会比较顺手。