fix: invalid prisma schema with format args#2677
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughAdds ID generator names list and updates Prisma schema function-call emission to strip format-style leading arguments for those generators; introduces a Vitest that generates a schema from an inline model and asserts expected ID generator call forms. ChangesID Generator Function Argument Handling
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
packages/sdk/src/prisma/prisma-schema-generator.ts (2)
387-391: ⚖️ Poor tradeoffSimplify the complex filter condition for maintainability.
The nested boolean logic is difficult to parse. The condition mixes special-casing for
ulidwith general ID function handling, making the intent unclear.♻️ Refactor to improve readability
makeFunctionCall(node: InvocationExpr): PrismaFunctionCall { + const functionName = node.function.ref!.name; + const isIdFunction = ID_FUNCTIONS.includes(functionName); + return new PrismaFunctionCall( - node.function.ref!.name, - - // strip format args from id functions - node.args.filter((_, i) => ( - !(ID_FUNCTIONS.includes(node.function.ref!.name) && (node.function.ref!.name === 'ulid' && i === 0 || i === 1)) - )).map((arg) => { + functionName, + node.args.filter((_, i) => { + if (!isIdFunction) return true; + // ulid: strip format arg at index 0 and any second arg + // others: strip format arg at index 1 + if (functionName === 'ulid') { + return i !== 0 && i !== 1; + } else { + return i !== 1; + } + }).map((arg) => {🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/sdk/src/prisma/prisma-schema-generator.ts` around lines 387 - 391, The filter's nested boolean is hard to read; simplify by first computing whether the call is an ID function (e.g., const isIdFn = ID_FUNCTIONS.includes(node.function.ref!.name)) and the index to exclude (e.g., const excludeIndex = node.function.ref!.name === 'ulid' ? 0 : 1), then replace the inline condition in node.args.filter((_, i) => ...) with a clear check like: if isIdFn return i !== excludeIndex else return true; keep the subsequent .map((arg) => ...) unchanged so the behavior is identical but much easier to maintain and understand.
387-391: 💤 Low valueConsider edge case: functions with 3+ arguments.
The current filter keeps arguments at index 2 and beyond for all ID functions. If a user accidentally provides extra arguments beyond the format string, those will pass through to Prisma, potentially causing schema validation errors.
Consider whether arguments at index ≥2 should also be stripped, or whether the generator should warn/error on unexpected argument counts.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/sdk/src/prisma/prisma-schema-generator.ts` around lines 387 - 391, The current filter can let through any arguments at index ≥2 for ID functions, causing unexpected extra args to reach Prisma; update the logic that filters node.args (referencing node.args, ID_FUNCTIONS, and node.function.ref!.name) to only allow explicit permitted indices per ID function (e.g., for 'ulid' allow only i === 0, for other ID_FUNCTIONS allow only i === 1) by computing an allowedIndices set for the given node.function.ref!.name and keeping args whose index is in that set, and additionally emit a warning or throw an error when node.args.length exceeds the expected count to surface accidental extra arguments.packages/cli/test/prisma-schema-gen.test.ts (1)
30-40: ⚡ Quick winConsider adding negative assertions to verify format strings are stripped.
The test validates that the expected function calls are present, but doesn't explicitly verify that the format strings (e.g.,
'cuid1_%s','uuid4_%s') are absent from the output. Adding negative assertions would strengthen confidence that the stripping logic works correctly.🧪 Example negative assertions
expect(prismaSchemaText.includes('nanoid(12)')).toBe(true); + + // Verify format strings are stripped + expect(prismaSchemaText.includes('cuid1_%s')).toBe(false); + expect(prismaSchemaText.includes('uuid4_%s')).toBe(false); + expect(prismaSchemaText.includes('ulid_%s')).toBe(false); + expect(prismaSchemaText.includes('nanoid12_%s')).toBe(false); });🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/cli/test/prisma-schema-gen.test.ts` around lines 30 - 40, Add negative assertions to the existing test that verify format strings are removed from the generated schema: after the positive checks on prismaSchemaText (e.g., cuid(), uuid(4), ulid(), nanoid()), add assertions that the original format strings like "cuid1_%s", "cuid2_%s", "uuid4_%s", "uuid7_%s", and any other pattern-based strings are not present in prismaSchemaText; use the same prismaSchemaText variable and the test framework's expectation helpers to assert those includes() calls return false (or toBe(false)) so the stripping logic is explicitly validated.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/cli/test/prisma-schema-gen.test.ts`:
- Around line 34-35: The test is missing an assertion that the generated schema
contains the no-argument UUID default; add an expectation asserting
prismaSchemaText.includes('uuid()') returns true alongside the existing checks
for 'uuid(4)' and 'uuid(7)'. Locate the assertions in the test file where
prismaSchemaText is checked (the expect calls for 'uuid(4)' and 'uuid(7)') and
add a similar expect(prismaSchemaText.includes('uuid()')).toBe(true) to cover
the field defined as uuid String `@default`(uuid()).
---
Nitpick comments:
In `@packages/cli/test/prisma-schema-gen.test.ts`:
- Around line 30-40: Add negative assertions to the existing test that verify
format strings are removed from the generated schema: after the positive checks
on prismaSchemaText (e.g., cuid(), uuid(4), ulid(), nanoid()), add assertions
that the original format strings like "cuid1_%s", "cuid2_%s", "uuid4_%s",
"uuid7_%s", and any other pattern-based strings are not present in
prismaSchemaText; use the same prismaSchemaText variable and the test
framework's expectation helpers to assert those includes() calls return false
(or toBe(false)) so the stripping logic is explicitly validated.
In `@packages/sdk/src/prisma/prisma-schema-generator.ts`:
- Around line 387-391: The filter's nested boolean is hard to read; simplify by
first computing whether the call is an ID function (e.g., const isIdFn =
ID_FUNCTIONS.includes(node.function.ref!.name)) and the index to exclude (e.g.,
const excludeIndex = node.function.ref!.name === 'ulid' ? 0 : 1), then replace
the inline condition in node.args.filter((_, i) => ...) with a clear check like:
if isIdFn return i !== excludeIndex else return true; keep the subsequent
.map((arg) => ...) unchanged so the behavior is identical but much easier to
maintain and understand.
- Around line 387-391: The current filter can let through any arguments at index
≥2 for ID functions, causing unexpected extra args to reach Prisma; update the
logic that filters node.args (referencing node.args, ID_FUNCTIONS, and
node.function.ref!.name) to only allow explicit permitted indices per ID
function (e.g., for 'ulid' allow only i === 0, for other ID_FUNCTIONS allow only
i === 1) by computing an allowedIndices set for the given
node.function.ref!.name and keeping args whose index is in that set, and
additionally emit a warning or throw an error when node.args.length exceeds the
expected count to surface accidental extra arguments.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 6ed948ab-9c29-42c2-b0d0-2168e5d79cda
📒 Files selected for processing (2)
packages/cli/test/prisma-schema-gen.test.tspackages/sdk/src/prisma/prisma-schema-generator.ts
Prisma errors when the ID format args are left as is. This PR strips them during Prisma schema generation.
https://discord.com/channels/1035538056146595961/1506671487745265796/1506671487745265796
Summary by CodeRabbit
Tests
Improvements