Cloudflare 发布 Vinext 1.0：支持 Vite 的 Next.js 应用迁移与部署框架

当我们二月份推出 Vinext时，这是一项大胆的、为期一周的 AI 驱动实验的成果，旨在探索一名工程师和一堆 token 能在多大程度上复制由 Vite 支持的 NextJS 框架。

自那次实验以来的七个月里，Vinext 已经成长为一个深受客户信赖的框架，并被用于高流量、动态应用程序的生产环境中。

今天，我们宣布发布 Vinext 1.0，这是我们实现“让 Next.js 应用随处部署”这一愿景的最新一步。Vinext 让你可以获取任何 Next.js 应用程序（无论是为 Pages Router 还是 App Router 构建的），并使其具备可移植性，从而能够部署到任何 Web 平台，包括 Cloudflare Workers 免费计划、Netlify 或 AWS Lambda。

Vinext 1.0 在兼容性、稳定性和缓存行为方面带来了全面改进，并为该项目的长期发展奠定了基础。现在是将你的 Next.js 项目转换为 Vinext 的最佳时机；只需运行 npx vinext check 和 npx vinext init。

迈向 1.0 版本

Vinext 在发布之初虽有潜力，但并不完整。自那时起，我们花费了大量时间来改进 App Router 的兼容性，并将其扩展到 Pages Router 应用——我们了解到许多客户是后者的长期拥趸，且拥有难以迁移的大型复杂应用程序。我们不希望 Vinext 仅仅成为一个只适用于使用最新 App Router 功能的用户的工具。

我们的重点一直是采用这两种路由，并密切关注我们的测试兼容性，目前对于大多数客户要求的重要功能，兼容性已超过 99%。

这一改进得益于我们 GitHub 项目 周围的社区。Vinext 一经发布，社区成员就将其应用于各种各样的应用程序中以寻找漏洞。在他们的审视下，我们发现了测试覆盖范围中并不显眼的挑战。Vinext 需要的行为必须与 Next.js 完全一致。仅仅模仿同名函数是不够的。构建一个替代品 import { revalidatePath } 很简单；难点在于确保它能正确影响渲染页面、缓存条目和后续请求。

通过应用程序追踪请求以确保 Vinext 以预期方式响应——不仅是复制 API，还要复制其底层机制的行为——是迄今为止最具挑战性的方面。

一旦我们修复了问题并推出了新功能，确保不出现回归就变得至关重要，尤其是当 Next.js 发生变更时。这就是为什么我们还构建了测试套件：数千个针对性的测试，涵盖了两种路由、开发和生产服务器，以及 Nodejs 和 Cloudflare Workers 部署目标的核心框架行为。我们还每天针对 Vinext 运行 Next.js 端到端测试套件，这让我们能持续了解兼容性情况，并确保能立即察觉合并变更带来的回归。除了自动化测试之外，我们还直接与在生产环境中使用 Vinext 的大型客户合作，以确保他们不会遇到问题。

1.0 版本包含的内容

我们从使用 Vinext 的客户那里得到的最明确的信息是，某些 Next.js 功能是框架的核心，而 Vinext 实际上并不需要完成 Next.js 近期版本中推出的所有功能就能对他们产生巨大的价值。因此，我们将重点放在了在您需要的地方提供更好的支持：

• App Router、Pages Router 和混合应用程序：我们从客户那里了解到，Pages Router 仍然很重要，而且迁移并非一步到位。因此，Vinext 支持这两种路由路径，包括 React Server Components、Server Actions、API 路由、路由处理程序、中间件和客户端导航。
• 完整的页面生命周期：页面可以通过多种不同方式进行渲染：在服务器上渲染、在构建时预渲染、导出为静态资源，或通过页面级增量静态再生（ISR）进行缓存。我们确保了后台和按需重新验证适用于任何输出。
• 缓存：Vinext 在 App Router 和 Pages Router 以及受支持的运行时之间提供了一套共享的缓存函数。我们进一步支持使用 Cloudflare 的 Workers Cache。
• 可观测性：Vinext 在两个路由器中提供兼容 Next.js 的追踪功能，因此现有的 OpenTelemetry 和 Sentry 设置可以继续工作。在 Cloudflare Workers 上，追踪功能还与原生的 Workers 可观测性集成。
• Next.js 生态系统兼容性： Vinext 实现了公共 next/* 接口，并支持常见的 Next 模式，用于身份验证、MDX、图像优化、字体、元数据、环境变量等。
• 对 Workers 的一流运行时支持：虽然 Vinext 可以在任何地方运行，但服务器代码可以在开发和生产环境中的 Cloudflare workerd 运行时中运行，并可直接访问图像优化和 hyperdrive 等绑定。 

我们还将迁移作为框架的一部分：只需两条命令即可验证您的 Next.js 安装及所做的任何修改是否兼容，并设置 Vite 和部署配置，同时保留您之前所有的 Next.js 项目结构。

当我们与团队讨论哪些功能对他们重要时，有一点非常突出。Next.js 16 认为 Cache Components 是该框架未来的重要组成部分，然而我们交谈过的大多数团队并没有使用它们，也不认为这是迁移的先决条件。因此，Vinext 目前对驱动 Cache Components 的“use cache”指令支持有限，虽然我们将继续提高这方面的兼容性，但我们更专注于上述核心优先级。

预渲染和缓存预热

当我们首次发布 Vinext 时，它支持首次请求后的增量静态再生（ISR），但尚不支持在构建期间渲染页面。应用程序使用 generateStaticParams() 和 getStaticPaths() 来识别构建时应渲染的页面，并期望页面级 ISR 将这些初始响应连接到后台和按需重新验证。

Vinext 1.0 为两个路由器都支持该生命周期。它可以在构建期间预渲染 App Router 和 Pages Router 路由，通过页面级 ISR 提供这些响应，并按路径或标签使其失效。它还支持当您需要完全静态站点时的 output: "export"。

但这让我们产生了一个疑问：为什么这种渲染必须在构建期间进行？

一个拥有数万甚至数十万个可能 URL 的网站，可能会花费极长的时间来渲染那些几乎没有流量的页面。构建过程无法评估大多数网站所经历的长尾流量，因此无法将计算时间集中在少数更关键的页面上。相反，你会在等待顺序构建处理数千个页面上浪费数小时，而此时最重要的路由早已完成。

缓存预热（Cache warming）是我们对此的解决方案，它将页面预渲染从构建机器转移到了 Cloudflare 的网络中。开发者可以继续使用 Next.js 原语来确定需要预渲染的页面，而 Vinext 还可以额外识别高流量页面并将其添加到此列表中。这一过程在你的网站部署到生产环境之前在后台完成，因此一旦部署，它就准备好从 Cloudflare 缓存中提供快速响应。

在部署过程中，其工作原理是上传一个新的 Worker 版本并将其部署到 0% 的生产流量中，然后专门从该版本请求页面。这使得渲染流水线能够在任何真实用户访问新部署之前就开始工作。一旦缓存被填充，就可以安全地提升该部署。

我们接下来的计划

如果最初的实验发明了一次性的 slopfork，那么更重要的部分在于我们如何能够无限期地保持这种自我改进的过程。

该项目目前专注于使框架与上游发生的一切保持同步。Next.js canary 每天都会收到新的提交。每天早上，一个代理会审查这些变更，获取差异，并为任何可能影响 Vinext 的内容开启跟踪问题。每天晚上，当我们针对 Vinext 运行 Next.js 测试套件时，兼容性矩阵都会重新生成。

当这些测试或问题中的某一个揭示出差距时，代理现在能够识别两个代码库之间的变更、构建复现、移植任何相关的测试并提出修复方案。

这种审查一直在捕捉缺失的案例、不安全的缓存行为以及开发服务器与生产服务器之间的差异。

自动化帮助我们将活动流缩小为一组值得关注的重点变更，使项目维护者能够只专注于那些需要了解流程应如何从 Next.js 实现映射到 Vite 的问题。

我们正在 Cloudflare 为开源构建一个软件工厂，你可以在 GitHub 上查看我们的进展。

试用一下

Vinext 适用于新应用程序和现有的 Next.js 项目。

立即开始一个新应用程序：

npm create vinext-app@latest my-app

或者迁移一个现有的应用程序：

npx vinext check && npx vinext init

然后将其部署到 Cloudflare Workers，并使用我们的缓存预热：

npx @vinext/cloudflare deploy --warm-cache

访问 vinext.dev 获取文档、示例和当前的兼容性矩阵。Vinext 是开源的，位于 github.com/cloudflare/vinext。欢迎提交问题、拉取请求、应用程序复现和反馈。