pnpm Monorepo 中使用 Prisma：隔离子应用的 @prisma/client
在使用 pnpm 管理的 Monorepo 项目中，多个子应用共享 Prisma 时，migrate 或 generate 命令可能导致 @prisma/client 被提升到根目录，从而影响其他子应用。本文探讨如何避免这种全局变更，确保每个子应用拥有独立的 @prisma/client 版本。
问题根源在于 pnpm 的依赖提升机制。 尝试使用 .npmrc 中的 hoist-pattern (例如 hoist-pattern[]=!@prisma/client 和 hoist-pattern[]=!prisma) 无效，因为 pnpm 的提升策略与 yarn 的 nohoist 不同。
解决方法：
推荐方案：独立的 Prisma Schema 和 Client
最佳实践是每个子应用拥有独立的 prisma/schema.prisma 文件，并使用 prisma generate 在各自目录下生成 @prisma/client。 这确保了每个子应用拥有独立的 @prisma/client 版本，避免冲突和不兼容性。 需要仔细管理每个子应用的 Prisma 配置，防止相互干扰。
其他方法 (较复杂，需深入理解 pnpm):
- 精细化依赖管理: 深入研究 pnpm 的依赖解析机制，通过精确的 package.json 配置来控制依赖安装位置，最大限度地避免 @prisma/client 被提升到不必要的层级。 这需要对 pnpm 的内部工作原理有深入的了解。
通过以上方法，特别是推荐的独立 Schema 和 Client 方法，可以有效防止 migrate 或 generate 命令导致 @prisma/client 在 pnpm Monorepo 中全局变更，从而确保子应用的独立性和稳定性。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
THE END
