從 Monolith 到 Monorepo：Next.js 遷移故事

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」最終導致了一系列意想不到的依賴關係：

• 我建立的整合庫
• 使用 MJML 和 React 範本建構的郵件系統
• Trigger.dev 工作流程分為 v2 和 v3

經驗教訓

這次遷移教會了我一些關於架構和開發實踐的重要課程：

1. 伺服器-客戶端分離很重要：雖然 Next.js 可以輕鬆混合伺服器和客戶端程式碼，但這種便利可能會導致混亂的架構。我發現自己跨邊界導入類型和常量，而沒有考慮其意義。

2. 從 Monorepo 開始：如果我今天重新開始，我會從第一天開始從 Turborepo 開始。它增加了最小的複雜性，同時迫使您以健康的方式思考依賴關係和架構。

3. 明確依賴關係更好：打破整體迫使我們可視化並質疑我們的依賴關係。這些連接有必要嗎？我們是否創建了循環依賴？這些限制促使我們做出更好的架構決策。

未來之路

遷移尚未完成。我們的伺服器程式碼和共享實用程式仍然需要適當的組織，並且我們正在重新考慮我們的模組結構，因為 tRPC 和資料庫層是分開的。但我們的開發體驗已經有了顯著改善。

對於建立可擴展的 Next.js 應用程式的任何人，請考慮從 monorepo 結構開始。初始投資很少，但它提供的建築護欄是無價的。未來的你以及你團隊的舊筆記型電腦都會感謝你。

以上是從 Monolith 到 Monorepo：Next.js 遷移故事的詳細內容。更多資訊請關注PHP中文網其他相關文章！