Vite+ Beta

Vite+ 的范围和使用场景

• 构建在 Vite 之上，因此继承了 Vite 以浏览器为中心的模型和限制。
• 人们已经在成功将 Vite（以及 Vite+）用于 Node 目标：NestJS 服务器、CLI 和 lambda，通常会配合 vite-plugin-node 等插件。
• 对于 CLI，你不会使用开发服务器，但仍然能受益于 lint、格式化、任务运行和缓存。

工具链集成与“无聊技术栈”之争

• Vite+ 将 Vite、Vitest、Rolldown、tsdown、Oxlint 和 Oxfmt 打包进一个连贯的工具链。
• 许多人把这视为正在形成的“无聊但好用”技术栈：采用成熟约定，用 Rust 重写以提升速度，并实现互操作。
• 也有人认为，真正“无聊”的技术栈应当包含更少的工具，以及更少的总体间接层。

性能、DX，以及 Node/TypeScript 工作流

• Vite 的开发构建和 HMR 受到称赞，但有人反馈，对基础应用来说，更简单的流程（esbuild + 手动刷新）会更快。
• Vitest 被描述为非常快且功能丰富，但一些用户发现，在大型、复杂图中它比 Jest 更慢；性能取决于具体场景。
• 关于在 Node 上运行 TypeScript 的讨论很多：tsx、node --strip-types、自定义 ESM loader，以及围绕 ESM 导入和扩展名处理的痛点。

复杂性、依赖与安全

• 若干评论批评现代 Web 开发“层层叠加”的特性，以及 Node 生态中的包泛滥。
• 一些团队在激进地减少依赖，甚至放弃第三方包，转而依赖 AI 辅助的定制代码。
• 在 CI 中预编译被认为比在生产环境中运行像 tsx 这样复杂的开发工具更安全。

版本频繁变动与稳定性

• Vite 的多个大版本（3–8）被引用为过度变动，并被视为将这种模型扩展到整个工具链时的警示信号。
• 也有人表示迁移非常简单（通常只需几处配置调整），并认为这些收益，尤其是在 SSR 方面，是值得的。

品牌、变现与所有权

• “+” 这个名称和营销风格让一些人联想到“订阅档位”，因此心存警惕。
• 线程中提到 Vite+ 采用 MIT 许可证，且其背后的公司已被 Cloudflare 收购；此前的变现尝试已被取消。
• 对试图管理运行时并成为“整个平台”的工具，仍然存在担忧，担心未来会出现锁定或“enshittification”。

替代方案与生态背景

• 讨论中将其与 uv（Python）、Bun、Deno、Laravel、Rails、ASP.NET Razor + htmx 等进行比较，反映出人们在更广泛地寻找更简单、更稳定的技术栈。
• 关于 Astro 兼容性的问题在帖子中没有得到回答（不明确）。