chore: bump prisma dependency to 6.0.x #1896
Conversation
|
Important Review skippedReview was skipped due to path filters ⛔ Files ignored due to path filters (7)
CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including You can disable this status message by setting the 📝 Walkthrough📝 Walkthrough📝 Walkthrough📝 Walkthrough📝 WalkthroughWalkthroughThis pull request updates the version numbers of the Changes
Possibly related PRs
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. 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: 2
🧹 Outside diff range and nitpick comments (2)
script/test-scaffold.ts (1)
22-22: Consider adding package.json version constraintsSince this is a test scaffold, consider adding these version constraints to the project's package.json to ensure consistent testing environments.
tests/integration/tests/cli/plugins.test.ts (1)
78-78:⚠️ Review impact of Prisma 6.0 breaking changesUpgrading to Prisma 6.0.x introduces breaking changes that might affect the tests. Please review the Prisma 6.0 release notes to ensure the test suite remains compatible.
Key areas to verify:
- Changes in client API
- Schema validation rules
- Migration engine behavior
- Query engine behavior
Consider adding test cases specifically for Prisma 6.0 features and breaking changes to ensure compatibility.
Also applies to: 88-88
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (7)
packages/runtime/package.jsonis excluded by!**/*.jsonpackages/schema/package.jsonis excluded by!**/*.jsonpackages/sdk/package.jsonis excluded by!**/*.jsonpnpm-lock.yamlis excluded by!**/pnpm-lock.yaml,!**/*.yamltests/integration/test-run/package.jsonis excluded by!**/*.jsontests/integration/tests/frameworks/nextjs/test-project/package.jsonis excluded by!**/*.jsontests/integration/tests/frameworks/trpc/test-project/package.jsonis excluded by!**/*.json
📒 Files selected for processing (2)
script/test-scaffold.ts(1 hunks)tests/integration/tests/cli/plugins.test.ts(2 hunks)
🔇 Additional comments (1)
script/test-scaffold.ts (1)
22-22: Verify compatibility with other dependencies
The command also installs other dependencies like zod and decimal.js. Please verify that these packages are compatible with Prisma 6.0.x.
Let's check for any potential compatibility issues:
✅ Verification successful
Let me gather more information about the specific versions and usage patterns.
Based on the gathered information, I can now provide a final response:
Dependencies are compatible with Prisma 6.0.x
The codebase shows proper integration between Prisma, Zod, and decimal.js:
- decimal.js is used at version ^10.4.2 which is fully compatible with Prisma 6.0.x
- Zod is used at version ^3.22.4 and is properly integrated with Prisma's types including Decimal
- The codebase includes proper type handling and serialization for Decimal types between Prisma and Zod
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for compatibility between dependencies
# Search for Zod usage with Prisma
echo "Checking Zod integration with Prisma:"
rg -g '!node_modules' 'zod.*prisma|prisma.*zod'
# Search for decimal.js usage with Prisma
echo "Checking decimal.js integration with Prisma:"
rg -g '!node_modules' 'decimal.*prisma|prisma.*decimal'
Length of output: 3006
Script:
#!/bin/bash
# Check package.json files for dependency versions
echo "Checking package.json files:"
fd package.json --exec cat {}
# Check for decimal.js type usage
echo -e "\nChecking decimal.js type usage:"
rg -g '!node_modules' 'Decimal|decimal\.js' -A 2
# Check for Zod schema definitions
echo -e "\nChecking Zod schema definitions:"
ast-grep --pattern 'z.object({
$$$
})'
Length of output: 93785
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (3)
packages/sdk/src/dmmf-helpers/select-helpers.ts (2)
64-64: Optimize by cachingprismaVersionto prevent redundant calls.
getPrismaVersion()is called in multiple functions (generateModelCountOutputTypeArgsInputObjectTypesandgenerateModelSelectInputObjectTypes). Consider retrievingprismaVersiononce at a higher scope and passing it as a parameter to these functions to avoid unnecessary repeated calls.Apply this diff to retrieve
prismaVersiononce and pass it as an argument:// Retrieve prismaVersion once +const prismaVersion = getPrismaVersion(); export function addMissingInputObjectTypesForSelect( inputObjectTypes: DMMF.InputType[], outputObjectTypes: DMMF.OutputType[], models: readonly DMMF.Model[] ) { // existing code - const modelCountOutputTypeArgsInputObjectTypes = - generateModelCountOutputTypeArgsInputObjectTypes(modelCountOutputTypes); + const modelCountOutputTypeArgsInputObjectTypes = + generateModelCountOutputTypeArgsInputObjectTypes(modelCountOutputTypes, prismaVersion); - const modelSelectInputObjectTypes = generateModelSelectInputObjectTypes(models); + const modelSelectInputObjectTypes = generateModelSelectInputObjectTypes(models, prismaVersion); // existing code } -function generateModelCountOutputTypeArgsInputObjectTypes(modelCountOutputTypes: DMMF.OutputType[]) { +function generateModelCountOutputTypeArgsInputObjectTypes( + modelCountOutputTypes: DMMF.OutputType[], + prismaVersion: string +) { // existing code - const prismaVersion = getPrismaVersion(); // existing code } -function generateModelSelectInputObjectTypes(models: readonly DMMF.Model[]) { +function generateModelSelectInputObjectTypes( + models: readonly DMMF.Model[], + prismaVersion: string +) { // existing code - const prismaVersion = getPrismaVersion(); // existing code }Also applies to: 99-99
68-71: Refactor repeated version checks to improve maintainability.The condition
prismaVersion && semver.gte(prismaVersion, '6.0.0')is used multiple times to determine type names based on the Prisma version. Consider extracting this logic into a helper function or variable to reduce duplication and enhance code readability.For example, define a helper function:
function isPrismaVersionAtLeast6(prismaVersion: string): boolean { return semver.gte(prismaVersion, '6.0.0'); }Then use it in your code:
- name: - prismaVersion && semver.gte(prismaVersion, '6.0.0') - ? `${modelCountOutputTypeName}DefaultArgs` - : `${modelCountOutputTypeName}Args`, + name: isPrismaVersionAtLeast6(prismaVersion) + ? `${modelCountOutputTypeName}DefaultArgs` + : `${modelCountOutputTypeName}Args`, // Similarly update other occurrences: - type: isList - ? `${type}FindManyArgs` - : prismaVersion && semver.gte(prismaVersion, '6.0.0') - ? `${type}DefaultArgs` - : `${type}Args`, + type: isList + ? `${type}FindManyArgs` + : isPrismaVersionAtLeast6(prismaVersion) + ? `${type}DefaultArgs` + : `${type}Args`, - type: - prismaVersion && semver.gte(prismaVersion, '6.0.0') - ? `${modelName}CountOutputTypeDefaultArgs` - : `${modelName}CountOutputTypeArgs`, + type: isPrismaVersionAtLeast6(prismaVersion) + ? `${modelName}CountOutputTypeDefaultArgs` + : `${modelName}CountOutputTypeArgs`,Also applies to: 112-116, 144-147
packages/sdk/src/dmmf-helpers/modelArgs-helpers.ts (1)
57-60: Enhance readability by extracting conditional naming logicTo improve readability, consider extracting the conditional assignment of the
nameproperty into a separate variable.Apply the following diff to refactor:
+ const isPrisma6OrAbove = prismaVersion && semver.gte(prismaVersion, '6.0.0'); + const inputObjectName = isPrisma6OrAbove + ? `${modelName}DefaultArgs` // Prisma 6+ removed [Model]Args type + : `${modelName}Args`; const modelArgsInputObjectType: DMMF.InputType = { - name: - prismaVersion && semver.gte(prismaVersion, '6.0.0') - ? `${modelName}DefaultArgs` // Prisma 6+ removed [Model]Args type - : `${modelName}Args`, + name: inputObjectName, constraints: { maxNumFields: null, minNumFields: null, }, fields, };
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
packages/plugins/trpc/tests/projects/t3-trpc-v11/package-lock.jsonis excluded by!**/package-lock.json,!**/*.json
📒 Files selected for processing (3)
packages/sdk/src/dmmf-helpers/include-helpers.ts(4 hunks)packages/sdk/src/dmmf-helpers/modelArgs-helpers.ts(3 hunks)packages/sdk/src/dmmf-helpers/select-helpers.ts(5 hunks)
🔇 Additional comments (7)
packages/sdk/src/dmmf-helpers/select-helpers.ts (1)
1-2: Importing 'semver' module for version comparison is appropriate.
The addition of semver is necessary for accurate version comparison when handling Prisma versions.
packages/sdk/src/dmmf-helpers/include-helpers.ts (4)
1-2: Import statements added correctly for version handling
The imports for semver and getPrismaVersion are necessary to introduce conditional logic based on the Prisma version.
18-18: Retrieving Prisma version for conditional logic
Using getPrismaVersion() allows the code to adjust behavior based on the installed Prisma version, ensuring compatibility.
37-41: Conditional logic correctly adjusts input types based on Prisma version
The nested ternary operator adjusts the input type according to whether isList is true and the Prisma version, ensuring compatibility with Prisma 6.0.0 and above.
67-70: Correctly updates _count field input type for Prisma 6.0.0 compatibility
The conditional logic ensures that the correct input type is used for the _count field, aligning with the changes in Prisma 6.0.0.
packages/sdk/src/dmmf-helpers/modelArgs-helpers.ts (2)
17-17: Use of 'prismaVersion' for conditional logic is appropriate
Retrieving prismaVersion using getPrismaVersion() to implement version-specific logic is correct.
1-1: Ensure 'semver' is added to project dependencies
The semver module is imported; verify that it is listed in the project's dependencies to prevent runtime issues.
Run the following script to check if semver is included in package.json dependencies:
✅ Verification successful
Let me check if semver might be in devDependencies or if it's a dependency of another package.
Let me check the workspace/monorepo setup since this is in the SDK package.
semver is already properly listed in dependencies
The semver package is correctly listed in the SDK package's dependencies with version ^7.5.2. No action is required as the dependency is already properly configured.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if 'semver' is specified in 'dependencies' within 'package.json'
# Test: Look for 'semver' in dependencies. Expect: A valid version string if present.
jq '.dependencies.semver' package.json
Length of output: 43
Script:
#!/bin/bash
# Check both dependencies and devDependencies for semver
echo "Checking package.json for semver in all dependency types:"
jq '{dependencies: .dependencies.semver, devDependencies: .devDependencies.semver}' package.json
# Check if semver exists in any package-lock.json or yarn.lock
echo -e "\nChecking for lock files:"
fd -e json -e lock "package-lock.json|yarn.lock"
# If yarn.lock exists, search for semver in it
if [ -f "yarn.lock" ]; then
echo -e "\nSearching yarn.lock for semver:"
rg "semver" yarn.lock -A 2
fi
# If package-lock.json exists, search for semver in it
if [ -f "package-lock.json" ]; then
echo -e "\nSearching package-lock.json for semver:"
rg "semver" package-lock.json -A 2
fi
Length of output: 652
Script:
#!/bin/bash
# Check package.json in the SDK package directory
echo "Checking SDK package.json:"
cat packages/sdk/package.json | jq '{dependencies: .dependencies.semver, devDependencies: .devDependencies.semver}'
# Also check workspace dependencies if this is a monorepo
echo -e "\nChecking for workspace root package.json:"
if [ -f "package.json" ]; then
echo "Workspace dependencies:"
jq '{workspaceDependencies: .dependencies.semver, workspaceDevDependencies: .devDependencies.semver}' package.json
fi
# Check if semver is used elsewhere in the SDK
echo -e "\nChecking other usages of semver in SDK:"
rg "semver" packages/sdk/src/ -l
Length of output: 912
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
packages/server/tests/api/rpc.test.ts (1)
345-348: Improve 'Uint8Array' content comparison in tests.When asserting equality of
Uint8Arrayinstances, comparing their contents ensures accurate validation. Direct comparison might not yield the expected results due to reference differences.Consider updating the assertions to compare the contents:
expect(data.bytes).toBeInstanceOf(Uint8Array); +expect(Array.from(data.bytes)).toEqual(Array.from(bytesValue)); expect(data.bars[0].bytes).toBeInstanceOf(Uint8Array); +expect(Array.from(data.bars[0].bytes)).toEqual(Array.from(barBytesValue));packages/plugins/openapi/tests/openapi-rpc.test.ts (1)
Line range hint
20-104: Address potential test conflicts due to fixed output paths.Changing the OpenAPI specification output to a fixed path (
$projectRoot/openapi.yaml) may cause tests to interfere with each other when run concurrently, leading to flaky behavior.To prevent file conflicts, consider using unique output paths for each test run. You can modify the output to include unique identifiers:
output = '$projectRoot/openapi.yaml' + output = '$projectRoot/openapi-${specVersion}${omitInputDetails ? "-omit" : ""}-${Date.now()}.yaml'Additionally, update the references to the output file accordingly to ensure each test reads its respective specification file.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (9)
packages/plugins/openapi/tests/baseline/rpc-3.0.0.baseline.yamlis excluded by!**/*.yamlpackages/plugins/openapi/tests/baseline/rpc-3.1.0.baseline.yamlis excluded by!**/*.yamlpackages/plugins/trpc/tests/projects/nuxt-trpc-v10/package-lock.jsonis excluded by!**/package-lock.json,!**/*.jsonpackages/plugins/trpc/tests/projects/nuxt-trpc-v10/package.jsonis excluded by!**/*.jsonpackages/plugins/trpc/tests/projects/nuxt-trpc-v11/package-lock.jsonis excluded by!**/package-lock.json,!**/*.jsonpackages/plugins/trpc/tests/projects/nuxt-trpc-v11/package.jsonis excluded by!**/*.jsonpackages/plugins/trpc/tests/projects/t3-trpc-v10/package.jsonis excluded by!**/*.jsonpackages/plugins/trpc/tests/projects/t3-trpc-v11/package-lock.jsonis excluded by!**/package-lock.json,!**/*.jsonpackages/plugins/trpc/tests/projects/t3-trpc-v11/package.jsonis excluded by!**/*.json
📒 Files selected for processing (4)
packages/plugins/openapi/tests/openapi-rpc.test.ts(4 hunks)packages/server/tests/api/rest.test.ts(5 hunks)packages/server/tests/api/rpc.test.ts(5 hunks)tests/integration/tests/e2e/type-coverage.test.ts(1 hunks)
🔇 Additional comments (3)
packages/server/tests/api/rest.test.ts (1)
Line range hint 2704-2810: Ensure consistent handling of 'bytes' fields with 'Uint8Array'.
The update from using Buffer to Uint8Array for the bytes field aligns with modern JavaScript standards for handling binary data. Confirm that all serialization and deserialization processes, especially with SuperJSON, properly handle Uint8Array instances to prevent potential data inconsistencies.
tests/integration/tests/e2e/type-coverage.test.ts (1)
51-51: Update 'Bytes' field to use 'Uint8Array' for binary data.
Changing the Bytes field to new Uint8Array([1, 2, 3, 4]) ensures consistency in handling binary data across the application. This aligns with the deprecation of Buffer in certain contexts and promotes compatibility with modern binary data handling practices.
packages/server/tests/api/rpc.test.ts (1)
307-308: Initialize 'bytes' fields with 'Uint8Array' for consistency.
Using Uint8Array for bytesValue and barBytesValue standardizes binary data handling throughout the test suite. This change enhances consistency and aligns with updates made elsewhere in the codebase.
No description provided.