我把 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.jsonnpm 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里处理依赖版本它应该会比较顺手。