VS Code 中的白色光标无声闪烁，但没有出现类型提示。我同事沮丧的叹息声在我们的 Slack 通话中回响——他的旧机器最终完全放弃了 TypeScript 建议。经过一年的构建 Next.js 应用程序，我们遇到了我一直担心的一堵墙：我们的整体代码库变得太大了，不舒服。
当我第一次开始这个项目时，Next.js 似乎是完美的选择。来自使用 React Router 和 Express 的普通 React SPA 背景，甚至更早的 PHP 经验，将服务器和客户端代码放在一起的想法感觉很直观。按照传统观点，我们根据功能而不是技术问题来组织代码。身份验证、潜在客户、帐户、团队功能 - 每个功能都位于自己的模块中，并具有自己的类型、实用程序、常量和服务器端代码。
“一开始很漂亮，”我记得在最初的几个月里我这样想。使用帐户模块意味着您需要的一切都在那里 - 组件、挂钩、tRPC 函数，甚至 Prisma 文件 - 全部都在一个文件夹中。这是我一直想要的开发者体验。
七个月后，第一个警告信号出现了。 TypeScript 的语言服务器开始陷入困境，建议出现的速度越来越慢，构建时间也在缓慢上升。虽然我强大的开发机器仍然可以处理它，但我同事的旧硬件完全屈服于复杂性。
我们面临着一个典型的工程十字路口：要么投入资金解决问题，要么投入工程时间来正确解决问题。当然，我们可以升级我们的硬件——TypeScript 性能只影响开发，而不影响生产。但这个解决方案感觉就像是创可贴。我们选择了更困难的道路：使用 Turborepo 将我们的整体重构为 monorepo。
第一步非常简单——迁移结构而不拆分任何代码。我创建了一个包含 Web 应用程序的 apps 文件夹，并添加了两个用于 ESLint 和 TypeScript 配置的标准 Turborepo 包。但真正的测试是在保留类型推断的同时移动我们的核心功能。
我从数据库层开始，将所有与 Prisma 相关的代码移至其自己的包中。经过一些 package.json 导出调整后，我屏住呼吸并检查了主应用程序中的类型。他们工作得很好。更好的是，当我的同事取消更改时，他几周来第一次收到了 IntelliSense 建议。我们正在做某件事。
接下来是 tRPC，这看起来很合乎逻辑——另一个独立的服务器端功能。但这就是事情变得有趣的地方。最初的“只是移动 tRPC”最终导致了一系列意想不到的依赖关系：
这次迁移教会了我一些关于架构和开发实践的重要课程：
服务器-客户端分离很重要：虽然 Next.js 可以轻松混合服务器和客户端代码，但这种便利可能会导致混乱的架构。我发现自己跨边界导入类型和常量，而没有考虑其含义。
从 Monorepo 开始：如果我今天重新开始，我会从第一天开始从 Turborepo 开始。它增加了最小的复杂性，同时迫使您以健康的方式思考依赖关系和架构。
显式依赖关系更好：打破整体迫使我们可视化并质疑我们的依赖关系。这些连接有必要吗？我们是否创建了循环依赖？这些限制促使我们做出更好的架构决策。
迁移尚未完成。我们的服务器代码和共享实用程序仍然需要适当的组织，并且我们正在重新考虑我们的模块结构，因为 tRPC 和数据库层是分开的。但我们的开发体验已经有了显着改善。
对于构建可扩展的 Next.js 应用程序的任何人，请考虑从 monorepo 结构开始。初始投资很少，但它提供的建筑护栏是无价的。未来的你以及你团队的旧笔记本电脑都会感谢你。
以上是从 Monolith 到 Monorepo：Next.js 迁移故事的详细内容。更多信息请关注PHP中文网其他相关文章！
