Turbopack Dev 现已稳定

历经漫长道路，我们很高兴地宣布 next dev --turbo 现已稳定，可以加速您的开发体验。我们一直在使用它来迭代 vercel.com、nextjs.org、v0 以及我们的所有其他应用程序，效果显著。

自 8 年前发布以来，Next.js 已被用于构建各种项目，从周末的业余爱好项目到复杂的企业应用程序。在 Next.js 首次发布时，webpack 显然是框架捆绑基础的最佳选择，但随着时间的推移，它在满足现代 Web 开发人员的需求方面显得力不从心。我们的社区开始发现，在等待路由加载、代码更改反映和生产版本部署时，迭代速度慢得令人痛苦。

我们投入了大量时间和精力优化 webpack，但在某个时候，我们觉得投入的精力与获得的改进不成正比。我们需要一个新的基础，既能支持当今已在生产环境中运行的众多 Next.js 应用程序，又能支持我们计划的未来创新，例如 React Server Components。

以下是我们对这个新捆绑器的要求：

最小的破坏性更改
同时支持 App Router 和 Pages Router
所有规模的代码库都能实现更快的编译时间
与生产环境高度一致的开发构建
高级生产优化（例如，模块内的 tree shaking）
支持 Node.js 和浏览器等多种环境的模块图
为维护者和高级用户提供全面的可观察性

我们评估了当时的所有现有解决方案，发现每个解决方案都有权衡，与我们的要求和目标不符。因此，从头开始设计一些能够完全满足 Next.js 今天需求的东西，并掌握路线图，以便我们能够构建和试验它未来需要的东西，对我们来说是有意义的。这就是我们创建 Turbopack 的动机。

我们首先优化了开发体验，这就是我们今天作为稳定版本发布的内容。我们一直在 Vercel 的应用程序中广泛地使用 Turbopack，并显着提高了我们开发人员的迭代速度。例如，对于 vercel.com 这样一个大型 Next.js 应用程序，我们看到：

本地服务器启动速度提升高达 76.7%。
使用 Fast Refresh 进行代码更新的速度提升高达 96.3%。
在没有缓存的情况下，初始路由编译速度提升高达 45.8%（Turbopack 尚不具备磁盘缓存）。

在这篇文章中，我们将讨论我们如何实现这些结果，以及其他一些亮点。我们还将明确说明对此版本的期望，并提供对未来发展的路线图。

亮点

更快的路由初始编译

我们社区听到的最大的问题之一是路由在开发过程中加载时间过长，这归根结底是 webpack 的编译速度问题。Next.js 按需编译路由，以避免在需要之前编译所有可能的路由，这保持了初始启动速度快和内存使用率低，但即便如此，您仍然可能会发现自己在焦急地等待单个页面加载。

公平地说，像 webpack 这样的捆绑器在底层做了很多工作。首次编译路由时，捆绑器从“入口点”开始。在 Next.js 中，它是 page.tsx 以及该路由的所有相关文件（如 layout.tsx 和 loading.tsx 等）的组合。解析这些入口点以查找 import 语句，这些语句被解析为文件，然后像入口点一样处理这些文件，并且此循环持续进行，直到找不到更多导入。此过程构建了一个模块图，该模块图不仅可以由 TypeScript/JavaScript 模块（包括 node_modules）组成，还可以由 CSS 文件（全局 CSS 和 CSS 模块）和静态文件（如 next/image 导入的图像）组成。

收集所有模块后，模块图用于创建 JavaScript 包，通常称为“chunks”。这些 chunks 是编译器在服务器（构建时或运行时）或浏览器上运行的输出。

webpack 不支持创建生成多种环境输出的图，因此我们今天必须在 Next.js 中使用 webpack 运行至少两个单独的编译器，一个用于服务器，一个用于浏览器。我们必须首先编译服务器模块图，以便可以找到对 "use client" 的所有引用。构建服务器后，我们遍历其图以创建浏览器编译器的相关入口点。由于这是一个单独的 webpack 编译器，因此此过程中存在一些开销，例如在客户端和服务器之间解析相同的代码两次。

通过 Turbopack，我们着手消除运行多个编译器并在它们之间进行协调的开销。解决方案是使编译器能够识别多个不同的输出目标。在内部，这些被称为目标“转换”。我们可以将导入标记为从服务器到浏览器或从浏览器到服务器的转换。这使得 Turbopack 能够有效地捆绑 Server Components 和 Client Components，以及从 Client Components 导入的 Server Functions。

除了提高性能外，拥有一个可以一次性处理多个环境的单一编译器还具有可靠性和调试优势，因为我们不再需要在 Next.js 中协调两个单独的编译器进程。

webpack 和 Turbopack 的另一个重大区别是，Turbopack 可以跨多个 CPU 并行处理工作，而 webpack 仅使用 SWC 并行处理 TypeScript/JavaScript 转换步骤。

webpack 不支持跨 CPU 并行处理，因为为了有效地并行处理，数据必须易于跨线程访问。webpack 的构建方式大量使用了大型 JavaScript 对象，这些对象无法在线程之间轻松共享，而无需昂贵的序列化和反序列化。这种开销通常会抵消利用多个 CPU 带来的性能提升。Turbopack 使用 Rust 编写，没有相同的限制，并且从一开始就考虑了并行化。

我们还通过更快的文件系统读取和写入、更快的模块解析以及跳过更多关于无副作用模块的工作获得了性能提升。

当在 vercel.com 这样一个大型 Next.js 应用程序上使用 Turbopack 时，我们看到初始编译速度比使用 webpack 的 Next.js 快了高达 45.8%。

更快的 Fast Refresh

Fast Refresh 是捆绑器用于将更改传播到您当前在浏览器中查看的路由的系统，有时称为热模块替换 (HMR)。

Next.js 具有更深层次的集成，将 Fast Refresh 连接到 React，确保 React 在您更改组件时不会丢失状态。

使用 webpack，我们发现当您达到一定数量的 JavaScript 模块时，Fast Refresh 的性能会受到限制。即使对于未更改的模块，Webpack 也需要进行图遍历并生成输出，并随着 JavaScript 模块的数量线性扩展。

我们发现，在大约 30,000 个模块时，代码更改始终至少有 1 秒的开销来处理更新，无论更改是否很小。例如，更改 CSS 文件中的颜色可能需要 1 秒才能在屏幕上显示出来。

这种性能对我们来说是不可接受的。我们认为，增量构建应该仅根据本地更改的大小进行扩展，而不是路由或应用程序的大小。当 button.tsx 更改时，编译器应该只运行与该文件更改相关的工作，而不是必须重新计算不受更改影响的其他模块和输出文件。为了解决这个问题，我们优先考虑在 Turbopack 中构建一个基础，允许对工作进行非常精细的重新计算。

这项努力转化为底层库 Turbo Engine，它使用自动按需驱动的增量计算架构，可在数十毫秒内提供大型 Next.js 和 React 应用程序的交互式热重载。此架构基于十多年的研究和现有技术，包括 webpack、Salsa、Parcel、Adapton 和 Rust 编译器的查询系统。

现在有了 Turbopack，Fast Refresh 速度可以根据更改的大小进行扩展，这就是我们能够在像 vercel.com 这样的大型 Next.js 应用程序上实现 96.3% 更快 的代码更新速度的原因。

高级追踪

随着 Next.js 多年来被广泛采用，我们发现越来越难以在 GitHub 上重现报告的问题，尤其是与编译器性能和内存使用相关的问题。这是因为大多数人无法共享他们的应用程序代码，或者当他们共享代码时，应用程序无法运行，因为它需要数据库或其他设置。

为了开始解决这个问题，我们在 Next.js 的内部添加了追踪功能。这些追踪信息被写入 .next 文件夹中的一个文件，并且不包含应用程序代码 - 仅包含文件路径、编译器花费的时间以及其他计时信息，例如单个转换。但是，对于 webpack，我们始终没有一种很好的方法来清楚地区分编译器的内存使用情况与框架或应用程序代码的内存使用情况，因为它们都在同一个 Node.js 实例中运行。

通过 Turbopack，我们能够从一开始就进行检测设计。我们在 Turbo Engine 中实现了一个检测层，允许收集每个单独函数的计时信息。我们能够扩展这些追踪信息，以跟踪每个函数的内存分配、释放和持久化内存。

这种新的高级追踪为我们提供了深入调查减速和内存使用情况所需的所有信息；它只需要一个追踪文件，而不是完整的代码库。

为了处理这些新的追踪信息，我们实现了一个自定义的追踪查看器，无论应用程序和追踪文件大小如何，它都能保持高性能。它是一个专门为调查 Turbopack 的减速和内存使用情况而构建的追踪查看器，并且由于它缩短了反馈循环，因此使我们能够优化许多早期采用者应用程序的性能。

虽然追踪查看器最初是为内部使用而构建的（并且它旨在用于需要深入技术探索的情况），但我们已经实现了在 Next.js 中自行运行它所需的组件。您可以使用这些说明生成 Turbopack 追踪文件。然后，当生成追踪文件后，您可以使用 next internal turbo-trace-server .next/trace-turbopack 启动服务器，以便检查追踪文件。此处提供了一个关于追踪查看器的快速视频概述：点击此处。

编译时间波动性更小

当将 Next.js 与 webpack 结合使用时，编译时间通常不够透明。在一种情况下，打开页面可能需要 10 秒，而在另一种情况下，可能需要 20 秒。虽然可能存在缓存，但有时它的影响不足以产生一致的结果。即使在没有缓存的情况下进行编译，我们也看到了一些差异。

Turbopack 的底层架构确保编译时间的差异更加一致。路由的编译时间仅变化几个百分点，这使我们能够持续优化编译器性能。

与生产环境高度一致的开发构建

为了优化 webpack 的编译速度，我们不得不接受一些权衡，这导致了开发环境和生产环境的分歧。这些权衡的一些示例包括我们使用 style-loader，它将样式注入到页面中，并允许对样式进行 Fast Refresh，而无需重新加载页面。但是，这意味着样式在开发过程中由 JavaScript 注入，这会导致未样式化内容的闪烁。我们解决了这种未样式化内容的闪烁问题，因此您不会看到它。另一个示例是，使用 webpack 的 Next.js 使用 eval-source-map，这意味着所有代码都包装在 eval 中，并且 sourcemap 也包含在其中，这确保了 sourcemap 在开发中可用，但代价是捆绑的代码更难以检查和调试。虽然 webpack 支持使用 source-map 选项输出完整的 sourcemap，但它会对编译时间和内存使用产生过大的影响。

对于 Turbopack，我们着手默认解决这些问题，输出 CSS 文件和 sourcemap，而不使用 eval。Turbopack 利用 sections sourcemaps，这是 source-map 规范中相对较新的部分，允许更有效地合并 sourcemap 输出。以前我们必须在一个地方生成所有映射，现在我们能够更精细地生成和缓存它们。

Turbopack 中的 CSS 处理始终输出 CSS 文件，并且与 JavaScript 处理类似，它可以通过 Turbopack 开发运行时的一部分机制更新 CSS 文件，而无需刷新浏览器。

我们现在可以自信地说，当某些东西在 Turbopack 的开发环境中工作时，它在生产环境中也能以相同的方式工作和表现。

我们的第一个稳定版本

两年前，我们在 Next.js 13 中以 alpha 版本推出了 Turbopack，预览了其性能潜力。虽然最初的结果很有希望，但它仅支持基本用法，许多 Next.js 功能（如 basePath）尚未实现。

在接下来的一年中，我们专注于添加缺失的 Next.js 和捆绑功能。根据社区反馈，我们决定完全专注于 next dev 体验，以便我们能够解决最常见的迭代速度问题。到去年 Next.js Conf 时，90% 的开发测试都通过了，Vercel 开发人员已经在日常开发中使用 Turbopack。

4 月，我们发布了 Next.js 14.2，其中 99.8% 的测试通过，此后不久达到了 100%。从那时起，我们解决了 GitHub 报告的问题，尤其是关于 npm 包、Fast Refresh 和错误位置准确性的问题。

诚然，走向稳定的道路花费了很长时间，但这主要归结于 Next.js 广泛的测试套件，它为稳定性设定了很高的标准。我们花了 8 年的时间来发现边缘情况，并添加了 6,599 个开发测试，这些测试也需要在 Turbopack 中通过。另一个因素是，我们设计的 Turbopack 与 webpack 的架构完全不同。简单地将 webpack 移植到 Rust 会更容易，但无法解锁我们想要实现的性能提升。

现在 Turbopack 通过了所有测试，已通过顶级 npm 包的验证，并且早期采用者的反馈也已解决，我们已准备好将其标记为稳定。

到底什么是稳定？

过去，这一直是一个令人困惑的点，因此我们将在此部分中澄清此版本为 Next.js 社区解锁的内容。

此版本专门将 next dev --turbo 命令标记为稳定。生产构建 (next build --turbo) 尚不受支持，但请继续阅读以获取更新，因为它们正在进行中。我们最终计划在 Next.js 之外发布 Turbopack 的独立版本，但我们希望首先通过增强 Next.js 社区的体验来证明其价值。

除了我们将在下一节中介绍的不受支持的功能外，Turbopack 应该可以与 Next.js 的所有稳定功能一起使用。为了明确起见，Turbopack 同时支持 App Router 和 Pages Router。实验性功能可能与 Turbopack 兼容，也可能不兼容，但它们肯定会在被标记为稳定时兼容。

如果您的应用程序具有 webpack 自定义，但仅添加了 webpack 加载器，您或许可以通过为 Turbopack 配置加载器来使用 Turbopack。您可以阅读文档，了解 Turbopack 中对 webpack 加载器的支持。

以下是经过验证可在 Turbopack 中使用的 webpack 加载器列表：

@svgr/webpack
babel-loader
url-loader
file-loader
raw-loader
tsconfig-paths-webpack-plugin - 开箱即用支持，无需插件。
大多数其他加载器也有效，因为我们支持 webpack 加载器 API 的子集。

大多数 CSS 和 CSS-in-JS 库都受支持

受支持
- Tailwind CSS
- @emotion/react
- Sass
- styled-components
- Bootstrap
- Antd
- node-sass
- JSS
- Emotion
- theme-ui（使用 Emotion）
- @chakra-ui/core（使用 Emotion）
- aphrodite
当前不支持
- Less - 您可以添加 less-loader。使用 webpack 的 Next.js 也不开箱即用支持 Less。
- @vanilla-extract/css - 使用自定义 webpack 插件 - 我们将研究未来支持所需钩子所需的工作。
- StyleX - 需要 Babel 转换和对 data: 属性的支持 - 我们将在 next build --turbo 稳定后研究支持 StyleX。

性能

我们想要强调的是，今天发布的版本的性能明显优于 webpack，但这并非最终的性能数值。我们一直遵循 Kent Beck 的著名公式“先使其工作，再使其良好，最后使其快速。” 到目前为止，我们的大部分精力都投入在“先使其工作”阶段，因为我们必须赶上 Next.js 和 webpack 的范围，它们已经成熟了近十年。

Turbopack 大量投入于其缓存基础设施，但您可能知道，缓存是软件开发中仅有的两个难题之一。从经验来看，我们知道在并非专门为此构建的架构中添加缓存可能会导致不良结果，因此我们甚至为最细粒度的函数启用了缓存。这意味着重建速度非常快，但代价是冷启动和内存使用量较高，我们正在努力实现更好的平衡。妙的是，我们可以使用我们在帖子前面提到的高级追踪功能来查找低效率之处，并分析哪些函数最值得缓存。

在过去的 3 个月中，我们已经取得了一些显著的改进。比较 Next.js 15 RC 2 中的 Turbopack 与 15 RC 1 中的 Turbopack，显示了这些优化的结果

平均内存使用量减少 25-35%。
对于包含数千个模块的大型页面，初始编译速度提高 30-50%。

Turbopack 的稳定版本包含一个内存缓存，每次重启开发服务器时都必须重建该缓存，对于大型应用程序，这可能需要 10 秒或更长时间。我们对在磁盘持久缓存上进行测试时看到的大幅提升感到非常兴奋，我们将在本文后面介绍。

破坏性变更

构建我们自己的打包器的巨大动力是需要尽可能地匹配 webpack 的现有行为，这是我们当时无法通过任何现有解决方案保证的。这包括文件解析的方式和 webpack 的较小功能，例如 webpackIgnore 注释，一些 npm 包会使用它。

不幸的是，为了使 Turbopack 和相关的 Next.js 实现面向未来，我们不得不移除一些功能。当您使用 webpack 时，这些功能仍然会受到支持。

有一些重点，让我们深入探讨一下我们不得不更改它们的原因

不支持 webpack() 配置。 Turbopack 不是 webpack，它没有相同的配置选项结构，尽管它确实支持许多相同的功能。具体来说，我们已经实现了对 webpack 加载器和 resolve 别名的支持。大多数转换代码的 webpack 加载器都开箱即用。一些执行特殊操作的 webpack 加载器，例如 webpack 子编译器和发出文件，则不受支持。

.babelrc 不会自动转换代码。 Turbopack 默认情况下利用 SWC。您仍然可以根据需要添加 babel-loader，但我们正在确保默认设置始终快速，并且这些设置在架构方面也合理。即使您配置了 .babelrc，我们也始终必须运行 SWC，以便处理其他优化。这类似于 webpack 始终必须运行 acorn 解析器以进行进一步优化。如果您将 SWC 而不是 Babel 与 Turbopack 一起使用，我们可以解析一次，并在整个 Turbopack 中自始至终利用相同的抽象语法树 (AST)。

一些较少使用的 CSS Modules 功能。 我们已将 CSS 处理从 PostCSS 切换到 Lightning CSS。 Lightning CSS 是一款速度明显更快的 CSS 编译器，它开箱即用地支持 CSS 转换、压缩和 CSS Modules。缺点是一些较少使用的功能不受支持。具体来说，:global 和 :local 伪选择器（它们的功能变体 :global() 和 :local() 仍然有效）、@value 和 :import / :export ICSS 规则。它也比其他 CSS 解析器更严格，并且会指出代码中的错误，而不是忽略它们。

在添加 Lightning CSS 的过程中，我们为该项目做出了贡献。例如，我们为 CSS Modules 实现了细粒度的选项，以禁用 CSS 网格前缀和 CSS Modules 的 pure 模式。这使得从 webpack 中的 css-loader 过渡到 CSS Modules 时，更容易采用 Lightning CSS。我们还改进了对不受支持的 CSS Modules 功能的错误提示。

我们感谢 Lightning CSS 的作者和维护者 Devon Govett，感谢他在此项目上的持续合作。

实验性功能。 由于我们专注于 Turbopack 在 Next.js 中的稳定性，因此我们决定首先关注 Next.js 中可用的稳定功能。

有关完整列表，请参阅文档页面。

路线图

Turbopack 已经取得了长足的进步，但仍有许多工作要做。即将推出的两个令人兴奋的功能是持久缓存和生产版本。我们预计发布顺序如下：

持久缓存 — 未来小版本
构建版本 Beta 版 — 未来小版本
构建版本候选版 — 未来小版本
构建版本稳定版 — 未来小版本
在 create-next-app 中推荐用于新应用程序 — 未来小版本
当您没有自定义 webpack 配置时，在 Next.js 中默认为 Turbopack — 未来主要版本

虽然 webpack 将保留在 Next.js 中，但我们预计由于 Turbopack 的优势，大多数 Next.js 应用程序都希望使用它。一旦 Turbopack 的生产版本完成，我们将开始工作以支持常用的 webpack 插件。

我们对 Turbopack 的未来有初步的计划，但我们希望将这篇文章限制在我们有信心在可预见的未来交付的内容上。我们可能只谈论两个功能，但其中涉及很多内容，因此值得深入探讨。

持久缓存（跨重启的快速刷新）

持久缓存意味着存储编译器完成的工作，以便在开发服务器重启或多个生产版本构建中重复使用。

简而言之，Turbopack 避免重复执行相同的工作，即使您重新启动。

正如在“更快的快速刷新”部分中提到的，我们构建了 Turbo Engine，以确保工作可以并行化和缓存，这样每当您更改文件时，我们只需运行与该文件更改相关的工作。如果我们可以为您提供跨重启和打开路由的这种体验呢？我们不必重做以前的开发会话中已经完成的编译工作。如果我们可以获得快速刷新的好处，但用于打开在以前的开发会话中编译的路由以及使用 next build 的多个构建呢？

这正是我们一直在努力的方向：Turbo Engine 的新存储层，该存储层支持将编译工作持久化到磁盘，并在启动开发服务器或再次构建时恢复它。

虽然 webpack 在 Next.js 中默认启用了磁盘缓存，但它有相当多的限制。值得注意的是，必须从磁盘恢复并读取到内存中才能使缓存的大部分正常工作。它从来没有真正感觉像是一个足够细粒度的缓存。例如，在 Vercel 上的较大型应用程序上，我们发现当缓存增长到足够大的大小时，webpack 磁盘缓存甚至可能比从头开始完成所有工作还要慢。

与 webpack 的现有磁盘缓存不同，Turbopack 的持久缓存真正感觉像是跨重启的快速刷新。首次编译需要 10 秒以上的路由，一旦编译过一次，从缓存中恢复只需不到 500 毫秒。

对于使用 Turbopack 的 next build，我们也看到了类似的结果，其中仅重新编译更改的文件，其他所有内容保持不变。在 next build 采取的多个步骤中，这会将花费的大部分时间从运行编译和打包转移到运行 TypeScript 类型检查。

持久缓存目前仍在开发中，因为我们希望首先使用我们内部的 Next.js 应用程序进行验证。初步结果非常令人鼓舞，并且随着我们不断优化这些热路径，性能会随着时间的推移变得更好。

一旦持久缓存稳定，它将默认启用。启用持久缓存不需要更改您的代码库。

如果您有兴趣测试持久缓存，请联系我们！

CSS 代码块拆分：进行中。此功能对于将 CSS 拆分为更小的代码块至关重要，从而允许仅为应用程序的每个部分加载必要的 CSS，这有助于减少加载时间并确保 CSS 规则的正确排序。
生产 JS 运行时：已完成。这确保了 JavaScript 运行时在生产环境中按预期运行，从而提供可靠性和稳定性。
基于内容的文件名哈希：尚未实现。基于内容的哈希将使我们能够根据内容生成文件名，从而在浏览器中实现更高效的长期缓存。

用户体验性能优化

用户体验性能是实现快速加载时间和高效资源利用率的关键。以下是我们正在努力的方向

JS 代码压缩：已完成。我们已经实现了 SWC 代码压缩，自 Next.js 13 以来，Next.js 已经将其与 webpack 一起使用。
CSS 代码压缩：已完成。使用 Lightning CSS 进行 CSS 代码压缩，这对于减小样式表的大小非常重要。
全局信息（整个应用程序优化）：已完成。 Turbopack 可以应用需要有关应用程序中所有路由的数据的优化，例如模块 ID 哈希。
Tree Shaking：部分完成。进行中。我们对 tree-shaking 提供了部分支持，这有助于消除未使用的代码并减小捆绑包大小。但是，在某些情况下，tree-shaking 尚未完全生效
- 动态导入：Tree shaking 对于动态导入（例如使用 next/dynamic）受到限制。
- 复杂导出：某些类型的导出，例如 export { foo as "string name" }。
- 非 ES 模块：CommonJS 模块不可 tree-shake。
- Barrel 文件：从 barrel 文件重新导出效率低下，并且在跳过无副作用模块方面存在限制。
- 碎片化：在某些情况下，tree-shaking 可能会创建过多的碎片，从而导致捆绑包效率低下。
模块 ID 哈希（部分）：进行中。模块 ID 哈希已部分实现，但我们正在努力提高性能。完全启用后，它将有助于减小最终捆绑包的大小。
导出名称混淆：进行中。这包括减小导出名称的大小以减小最终捆绑包的大小。
Scope Hoisting：尚未实现。 Scope hoisting 将通过将较小的 JavaScript 模块合并到单个作用域中来帮助减小捆绑包大小，从而减少开销并提高性能。
生产优化的 JS 代码块拆分：尚未实现。代码块拆分 JavaScript 以最大限度地减少重复对于提高加载性能至关重要，特别是对于较大的应用程序。

敬请期待

我们很高兴自信地推荐 next dev --turbo，并且我们迫不及待想听到它如何改善您的开发体验。立即试用，亲身感受性能提升。

这仅仅是开始 - 持久缓存和生产版本即将问世，这将为您的工作流程带来更快的速度和更高的可靠性。

当我们朝着确保正确性和优化性能以无缝处理即使是最大的应用程序的方向迈进时，我们将分享更多更新。请继续关注未来的版本和改进，因为我们正努力使 Turbopack 成为开发和生产版本的最佳解决方案。

贡献者

我们感谢成千上万的开发人员参与了 Turbopack Beta 版和候选发布阶段的测试、问题报告和修复验证。

此版本由以下人员为您带来

Turbopack 团队：Alex、 Benjamin、 Donny、 Justin、 Leah、 Maia、 Niklas、 OJ、 Tim、 Tobias 和 Will。
Next.js 团队：Andrew、 Hendrik、 Janka、 Jiachi、 Jimmy、 Jiwon、 JJ、 Josh、 Sam、 Sebastian、 Sebbie、 Shu、 Wyatt 和 Zack。
Next.js 文档 团队：Delba、 Rich、 Ismael 和 Lee。