VSCode与Zed 官宣拥抱Vite+：尤雨溪赚麻了

人越是经历 就越清楚觉得

人一辈子需要学会的就是失去

因为那是你唯一真正拥有的东西

前些日子，Vite+ 官方宣布了对 VS Code 和 Zed 两大编辑器的深度集成支持。这一动作，标志着这个尤神团队 VoidZero 打造的前端工具链，对于长期被 ESLint + Prettier 的配置复杂性和性能瓶颈折磨的前端来说，这无疑是一个解放生产力的信号。

Vite+ 是什么？不只是另一个构建工具

Vite+ 常被误解为 Vite 的“升级版”或“替代品”。实际上，它的定位更底层、更宏大：一个由 Rust 驱动的、下一代 JavaScript 工具链。

它的目标是统一和替换掉现代前端开发中碎片化的工具层，包括：

• • 代码检查 ：替代 ESLint
• • 代码格式化 ：替代 Prettier
• • 构建 ：可与 Vite 等构建工具集成

也许是看不惯前端 30 多年来工具链的零碎，尤神决定效仿当年的秦始皇一统六国书同文车同轨的壮举，决定用 rust 语言统一前端工具链。

其核心差异化优势在于 性能 和 一致性。通过使用Rust 重写核心功能，Vite+ 避免了传统 Node.js 工具在处理大型项目时的解释执行开销成本，带来了数量级的性能提升。

这种前端世界的大一统，就有点类似于rust里面的cargo，go里面的tool，虽然js在1995年就诞生了，但是在工具链这块始终比不上其他同时期的后端语言，比如Java的gradle。反观2000年之后出现的新语言比如go，rust，zig等在工具链的考虑和设计非常的人性化。

IDE 集成：从“命令行工具”到“编辑器原生体验”

Vite+ 对 VS Code 和 Zed 的支持，是其产品成熟度的重要体现。在此之前，Vite+ 还只是一个命令行工具：在终端里运行 vp check 进行代码检查和格式化。尽管性能优异，但卖相不好， “脱离编辑器” 的工作流意味着无法获得即时反馈（如代码编写时的实时飘红、保存时的自动格式化）。

这次官方推出的 Vite Plus Extension Pack (VS Code) 和 oxc-zed 扩展 (Zed)，将 Vite+ 的核心能力无缝植入了编辑器的原生体验中。

VS Code 集成：深度配置与自动化

在这里插入图片描述

Vite+ 在 VS Code 中的集成相当深入，远不止安装一个扩展那么简单：

1. 1.一键安装扩展包：VoidZero.vite-plus-extension-pack 包含了格式化 (Oxc) 和测试 (Vitest) 所需的核心扩展。
2. 2.自动配置 .vscode/settings.json：这是最有价值的部分。vp create 或 vp migrate 命令会自动写入编辑器配置，例如：
   • 3. 将 Oxc 设置为 JavaScript/TypeScript 的默认格式化器，并禁用 Prettier。
   • 4. 配置保存时自动格式化 (editor.formatOnSave)。
   • 5. 配置保存时自动执行代码修复 (source.fixAll.oxc)。
   • 6. 关键配置 oxc.fmt.configPath 指向 ./vite.config.ts，确保了编辑器行为与 Vite+ 的 fmt 配置块完全一致，消灭了“本地格式化和 CI 格式化结果不同”的常见问题。
3. 7.NPM 脚本面板集成：vp create 还会将 npm.scriptRunner 设置为 "vp"。这意味着在 VS Code 的 NPM Scripts 面板中点击运行脚本，实际会通过 Vite+ 的任务运行器执行，充分利用其性能优势。

Zed 集成：为性能而生的编辑器迎来最佳搭档

Zed 作为一款由原 Atom 团队打造、同样追求极致性能的编辑器，与 Vite+ 的“气质”不说是天生一对也算是情投意合了。其集成方式与 VS Code 类似，通过 .zed/settings.json 配置 oxc 和 oxfmt 作为语言服务器，为Vue 提供闪电般格式化和代码操作支持，并明确毫不留情禁用了 Prettier。

需要在zed的settings.json里面配置

{
  "lsp": {
    "oxlint": {
      "initialization_options": {
        "settings": {
          "run": "onType",
          "fixKind": "safe_fix",
          "typeAware": true,
          "unusedDisableDirectives": "deny"
        }
      }
    },
    "oxfmt": {
      "initialization_options": {
        "settings": {
          "fmt.configPath": "./vite.config.ts",
          "run": "onSave"
        }
      }
    }
  },
  "languages": {
    "JavaScript": {
      "format_on_save": "on",
      "prettier": { "allowed": false },
      "formatter": [{ "language_server": { "name": "oxfmt" } }],
      "code_action": "source.fixAll.oxc"
    },
    "TypeScript": {
      "format_on_save": "on",
      "prettier": { "allowed": false },
      "formatter": [{ "language_server": { "name": "oxfmt" } }]
    },
    "Vue.js": {
      "format_on_save": "on",
      "prettier": { "allowed": false },
      "formatter": [{ "language_server": { "name": "oxfmt" } }]
    }
  }
}

在这里插入图片描述

深度剖析：Vite+ 的优势

1. 性能与工程化的胜利

对于中小型项目，你可能感受不到 ESLint 或 Prettier 的龟速。但当一个单体仓库包含数百个包，一个组件库有成百上千个文件时，全量检查或格式化可能需要等待数分钟甚至久得可以让人看一集灵魂摆渡了。Vite+ 借助 Rust 和并行处理，能将这个时间缩短到毫秒级。这种“感知不到的延迟”才是现代开发工具应有的格局。

2. 配置统一：单一事实来源

这是我认为 Vite+ 最具价值的设计哲学。传统工具链下，你需要在多个配置文件（.eslintrc.js, .prettierrc.js, vite.config.ts）间来回同步规则，比如缩进、换行等。这极易导致配置漂移和团队协作中的争议。配置越多，人就越容易犯错和花样百出。

Vite+ 尝试通过 vite.config.ts 作为唯一的配置入口 来解决这个问题。这种解决风格很类似于当年Spring Boot 统一Spring时候的做法。这大大降低了心智负担，减少了与配置的精神内耗。

3. Vite+前景

对于 Vue 开发者而言，Vite+ 意味着更为顺滑的体验。

Vite+ 目前作为一个只有半岁不到的新工具，它仍然面临几个关键挑战：

1. 1.社区信任与惯性：开发者对 ESLint + Prettier 的组合已非常熟悉，配置方案多如牛毛。让他们相信一个相对较新的工具能“更好”，需要时间。
2. 2.非 Vue 项目的体验：目前 Vite+ 的宣传和文档很大程度上局限在 Vue 生态。对于使用更广泛的 React而言，Vite+ 是否能提供同等优秀的体验，是决定其能否真正“破圈”的关键。

出于好奇，我花了时间在自己项目尝试 Vite+ 的 zed 集成。亲自感受了保存时代码瞬间格式化、没有任何延迟的爽感，这简直是一种开发心智的升级：将更多精力从维护工具配置上解放出来，聚焦于业务逻辑本身。

VS Code 和 Zed 率先伸出橄榄枝，只是一个开始。当Vite+ 越来越成熟时，我们或许真的将进入一个更少配置、更快反馈、更少Bug 的前端开发新境界。