pnpm Monorepo 中使用 Prisma：隔離 @prisma/client，避免全局修改
在使用 pnpm 管理的 Monorepo 項目中，多個子應用依賴 Prisma 時，prisma migrate 或 prisma generate 命令可能會將 @prisma/client 提升到項目根目錄，影響其他子應用。本文探討如何避免這種全局修改，保持每個子應用的 @prisma/client 版本獨立。
問題：執行 Prisma 命令后，@prisma/client 被安裝到 Monorepo 根目錄，而非子應用的 node_modules 目錄，導致版本沖突。
已嘗試方案：使用 .npmrc 文件中的 hoist-pattern 來阻止 @prisma/client 和 prisma 的提升，但無效。yarn 的 nohoist 配置在 pnpm 中不可用。
解決方案：由于 pnpm 不支持 nohoist，需要采用其他策略：
-
更精細的依賴管理: 仔細檢查子應用的依賴關系，確保每個子應用擁有自己獨立的 @prisma/client 版本。避免共享依賴，即使版本號相同，也建議每個子應用單獨安裝。
-
嚴格的版本控制: 使用精確的版本號（例如 “@prisma/client”: “4.11.0”）而不是通配符版本號（例如 “@prisma/client”: “^4.11.0″），以防止意外的依賴升級導致沖突。
-
探索 pnpm 高級配置: 深入研究 pnpm 的 workspace 配置以及其他高級選項，例如 Filter-packages，尋找更細粒度的依賴管理方法，實現依賴隔離。 這可能需要對 pnpm 的工作機制有更深入的理解。
-
考慮不同的項目結構: 重新評估項目結構，考慮將 Prisma Schema 和生成的客戶端代碼與應用代碼更徹底地分離。這可能涉及到調整子應用的組織方式和依賴關系。
-
使用虛擬工作區 (Virtual Workspaces): 如果你的 Monorepo 非常龐大且復雜，可以考慮使用虛擬工作區來更好地隔離依賴。
沒有單一的、直接等效于 Yarn nohoist 的 pnpm 配置。解決方法需要結合多種策略，并根據項目的具體情況進行調整。 建議逐步嘗試以上方法，并監控 node_modules 目錄的變化來驗證效果。
