#1926 - carrot #2373
#1926 - carrot #2373
Conversation
|
WalkthroughThe changes introduce enhanced diagnostics to the PrismaExtension's build process. In the Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. ✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
packages/build/src/extensions/prisma.ts (2)
3-6: Consolidate duplicatednode:fsimports
readFileSyncandexistsSyncare imported from the same module in two separate statements. Collapsing them into a single import keeps the header tight and avoids accidental divergence down the road.-import { readFileSync } from "node:fs"; -import assert from "node:assert"; -import { existsSync } from "node:fs"; +import assert from "node:assert"; +import { existsSync, readFileSync } from "node:fs";
90-109: Synchronous file read and simplistic regex may degrade build-time UX
readFileSyncblocks the event-loop. In large monorepos or CI environments with parallel builds this can become noticeable.
Σ Replace withfs.promises.readFile(...)and await its result inside the existingtryblock.The generator-block regex (
/generator\s+(\w+)\s+\{([\s\S]*?)\}/g) will:
• mis-classify generators whose opening brace is on the next line,
• include commented-out blocks, and
• ignore nested braces or interpolated env expressions.
If the intent is purely heuristic logging that’s acceptable, but please add a short comment clarifying the trade-off so future maintainers don’t assume production-grade parsing.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
packages/build/src/extensions/prisma.ts(3 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)
**/*.{ts,tsx}: Always prefer using isomorphic code like fetch, ReadableStream, etc. instead of Node.js specific code
For TypeScript, we usually use types over interfaces
Avoid enums
No default exports, use function declarations
Files:
packages/build/src/extensions/prisma.ts
🧠 Learnings (12)
📓 Common learnings
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.468Z
Learning: Applies to internal-packages/database/**/*.{ts,tsx} : We use prisma in internal-packages/database for our database interactions using PostgreSQL
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to trigger.config.ts : Build extensions such as `additionalFiles`, `additionalPackages`, `aptGet`, `emitDecoratorMetadata`, `prismaExtension`, `syncEnvVars`, `puppeteer`, `ffmpeg`, and `esbuildPlugin` must be configured in `trigger.config.ts` as shown.
📚 Learning: applies to internal-packages/database/**/*.{ts,tsx} : we use prisma in internal-packages/database fo...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.468Z
Learning: Applies to internal-packages/database/**/*.{ts,tsx} : We use prisma in internal-packages/database for our database interactions using PostgreSQL
Applied to files:
packages/build/src/extensions/prisma.ts
📚 Learning: applies to trigger.config.ts : build extensions such as `additionalfiles`, `additionalpackages`, `ap...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to trigger.config.ts : Build extensions such as `additionalFiles`, `additionalPackages`, `aptGet`, `emitDecoratorMetadata`, `prismaExtension`, `syncEnvVars`, `puppeteer`, `ffmpeg`, and `esbuildPlugin` must be configured in `trigger.config.ts` as shown.
Applied to files:
packages/build/src/extensions/prisma.ts
📚 Learning: applies to **/trigger/**/*.{ts,tsx,js,jsx} : always generate trigger.dev tasks using the `task` func...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : ALWAYS generate Trigger.dev tasks using the `task` function from `trigger.dev/sdk/v3` and export them as shown in the correct pattern.
Applied to files:
packages/build/src/extensions/prisma.ts
📚 Learning: applies to **/trigger/**/*.{ts,tsx,js,jsx} : you must use `@trigger.dev/sdk/v3` when writing trigger...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : You MUST use `trigger.dev/sdk/v3` when writing Trigger.dev tasks.
Applied to files:
packages/build/src/extensions/prisma.ts
📚 Learning: before generating any code for trigger.dev tasks, verify: (1) are you importing from `@trigger.dev/s...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Before generating any code for Trigger.dev tasks, verify: (1) Are you importing from `trigger.dev/sdk/v3`? (2) Have you exported every task? (3) Have you generated any deprecated code patterns?
Applied to files:
packages/build/src/extensions/prisma.ts
📚 Learning: applies to **/trigger/**/*.{ts,tsx,js,jsx} : you must `export` every task, including subtasks, in tr...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : You MUST `export` every task, including subtasks, in Trigger.dev task files.
Applied to files:
packages/build/src/extensions/prisma.ts
📚 Learning: applies to **/trigger/**/*.{ts,tsx,js,jsx} : tasks must be exported, even subtasks in the same file....
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Tasks must be exported, even subtasks in the same file.
Applied to files:
packages/build/src/extensions/prisma.ts
📚 Learning: applies to **/trigger/**/*.{ts,tsx,js,jsx} : when implementing schema tasks, use `schematask` from `...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : When implementing schema tasks, use `schemaTask` from `trigger.dev/sdk/v3` and validate payloads as shown.
Applied to files:
packages/build/src/extensions/prisma.ts
📚 Learning: applies to **/trigger/**/*.{ts,tsx,js,jsx} : the `run` function contains your task logic in trigger....
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : The `run` function contains your task logic in Trigger.dev tasks.
Applied to files:
packages/build/src/extensions/prisma.ts
📚 Learning: applies to **/trigger/**/*.{ts,tsx,js,jsx} : when triggering a task from backend code, use `tasks.tr...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : When triggering a task from backend code, use `tasks.trigger`, `tasks.batchTrigger`, or `tasks.triggerAndPoll` as shown in the examples.
Applied to files:
packages/build/src/extensions/prisma.ts
📚 Learning: applies to **/trigger/**/*.{ts,tsx,js,jsx} : when using metadata in tasks, use the `metadata` api as...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : When using metadata in tasks, use the `metadata` API as shown, and only inside run functions or task lifecycle hooks.
Applied to files:
packages/build/src/extensions/prisma.ts
special PR for eric
Here’s a concise summary of the change set and the reason behind each edit.
What changed in
packages/build/src/extensions/prisma.tsImported
readFileSync• Enables reading the contents of
schema.prismaduringonBuildStart.Schema introspection & logging (inside
onBuildStart)• We now read the Prisma schema file and regex-extract every
generatorblock’sname,provider, and (if present)output.• The extracted data is written to the build logs (
context.logger.debug).• Wrapped in
try/catch, emitting a warning instead of failing the build if parsing ever throws.Extra log around “schema folder” detection (inside
onBuildComplete)• We already decide logic branches based on whether the schema’s parent folder is literally called
schema.• We now output the computed boolean plus the resolved path so it’s visible in the logs.
Minor TypeScript safety fix
• Cast
m[2]to string and provided a default ("") to satisfy the linter when parsing regex matches.Why we added these diagnostics
• Prisma v6.6+ introduces mandatory custom
outputpaths and a newprisma-clientgenerator.• Our extension’s current behaviour still assumes:
– Prisma client is generated in
node_modules(old default).– A special
prisma/schemafolder pattern.• Before we refactor the logic we need hard evidence of what a project’s schema actually declares and which path is chosen at runtime.
• The added logs will immediately show, during a build:
– Which generators exist (
prisma-clientorprisma-client-js).– Whether a custom
outputpath is configured.– Whether our “schema-folder” heuristic triggered.
• With that visibility we can confirm (or rule out) each of the failure hypotheses we listed and then implement the minimal behavioural changes with confidence.
No functional behaviour is changed yet—only richer debug output—so existing builds stay stable while we gather real-world data.