Problem Description

When using Trigger.dev with pnpm workspaces that utilize catalogs, the Prisma extension can intermittently select the wrong Prisma version during builds. This appears to be a race condition in the version resolution logic.

Environment

Repository Structure

project-root/
├── pnpm-workspace.yaml (with catalogs definition)
├── trigger.config.ts 
├── prisma/
│ └── schema.prisma
└── node_modules/

pnpm-workspace.yaml Configuration

packages:
 - src/trigger/*
catalogs:
 prisma:
 '@prisma/client': '~6.16.0'
 prisma: '~6.16.0'

trigger.config.ts

prismaExtension({
 schema: "prisma/schema.prisma",
 // version was sometimes needed to be specified explicitly to work around this issue
 version: "6.16.2",
 clientGenerator: "client"
})

Issue Details

The problem occurs when:

1. Using pnpm workspaces with multiple sub-packages
2. Using pnpm catalogs to centralize dependency versions
3. Prisma schema is in the root project directory
4. No explicit version is specified in the Prisma extension configuration

What Happens

• Sometimes the correct version is detected
• Sometimes the wrong version is selected

Root Cause

The issue stems from how resolvePackageJSON walks up the directory tree when resolving packages in pnpm's symlinked structure. It can find:

• The wrong package.json (parent workspace instead of @prisma/client)
• A marker package.json file with incomplete information
• Nothing at all due to symlink traversal issues

Current Workaround

Explicitly specify the version in trigger.config.ts:

prismaExtension({
 schema: "prisma/schema.prisma",
 version: "6.16.2", // Explicitly specify to avoid race condition
 clientGenerator: "client"
})

Solution

PR #2555 addresses this issue by:

1. Fixing the package.json resolution to verify the correct package is found
2. Adding fallback to read version directly from node_modules
3. Supporting pnpm workspace: protocol
4. Providing helpful error messages for catalog: references

Related PR: #2555