merge dev to main (v2.10.0) #1907
Conversation
📝 WalkthroughWalkthroughThe pull request includes updates across multiple files, primarily focused on version increments and enhancements to function signatures and test cases. Key changes include updating the version of the JetBrains plugin from "2.9.4" to "2.10.0", modifications to the handling of query keys and request cancellation in various React, Svelte, and Vue hooks, and the introduction of new test cases for regression and validation. Additionally, several files have been updated to ensure compatibility with Prisma version 6.0.x, including adjustments to argument naming conventions and error handling in tests. 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: 4
🧹 Outside diff range and nitpick comments (12)
packages/sdk/src/dmmf-helpers/include-helpers.ts (2)
37-41: Consider refactoring repeated version checks into a helper function.The conditional logic for selecting types based on Prisma version is repeated. Extracting this logic into a helper function can improve maintainability and reduce code duplication.
Example:
function getRelationFieldType(type: string, isList: boolean): string { if (isList) { return `${type}FindManyArgs`; } else if (prismaVersion && semver.gte(prismaVersion, '6.0.0')) { return `${type}DefaultArgs`; // Prisma 6+ removed [Model]Args type } else { return `${type}Args`; } }And then use:
type: getRelationFieldType(type, isList),
67-70: Duplicate version-specific logic detected; consider using the helper function.The logic for selecting the
_countfield type based on Prisma version is similar. Utilizing the helper function can reduce redundancy.packages/sdk/src/dmmf-helpers/select-helpers.ts (3)
68-71: Consider refactoring version-based naming logic to reduce duplication.The conditional selection of type names based on Prisma version is repeated. Extracting this logic into a helper function would improve maintainability.
112-116: Duplicate conditional logic detected; consider using a helper function.The type selection logic for relation fields is similar to previous instances. Refactoring into a shared function can reduce code duplication.
144-147: Repeated version-based type selection; consider refactoring.Consolidating the version check logic into a helper function enhances code clarity and maintenance.
packages/server/tests/api/rest.test.ts (1)
2779-2779: Use 'toEqual' for comparing 'Uint8Array' contents instead of 'toString()'.When comparing
Uint8Arrayinstances, usingtoEqualdirectly compares the contents byte by byte, which is more accurate than converting to strings.Apply this diff to improve the assertion:
-expect(data.bytes.toString()).toEqual(updateAttrs.bytes.toString()); +expect(data.bytes).toEqual(updateAttrs.bytes);tests/regression/tests/issue-1870.test.ts (1)
1-1: Consider adding test description.Add a description to the test case to document what aspect of issue #1870 is being tested.
import { loadModel, loadSchema } from '@zenstackhq/testtools'; + +/** + * Regression test for issue #1870 + * Validates support for PostGIS geometry types and Gist indexes + */script/test-scaffold.ts (1)
22-22: Consider documenting Prisma 6.0.x migration steps.Major version upgrades often require specific migration steps. Consider adding a comment or documentation about required migration steps.
run('npm init -y'); +// Prisma 6.0.x migration steps: +// 1. Update schema.prisma +// 2. Run prisma generate +// 3. Update client instantiation if needed run('npm i --no-audit --no-fund typescript [email protected] @prisma/[email protected] zod decimal.js @types/node');tests/regression/tests/issue-1894.test.ts (1)
35-39: Consider testing error scenarios.The test only covers the happy path. Consider adding test cases for error scenarios.
async function main() { const db = enhance(new PrismaClient()); await db.a.create({ data: { id: 0 } }); await db.c.create({ data: { a: { connect: { id: 0 } } } }); + + // Test error scenarios + await expect( + db.c.create({ + data: { a: { connect: { id: 999 } } } + }) + ).rejects.toThrow(); }packages/sdk/src/dmmf-helpers/modelArgs-helpers.ts (1)
57-60: Add a comment explaining the version-specific behaviorConsider adding a comment block above this conditional to document why different type names are used for different Prisma versions. This will help future maintainers understand the version-specific behavior.
+ // Prisma 6.0.0 removed the [Model]Args type in favor of [Model]DefaultArgs + // We need to use different type names based on the Prisma version for compatibility name: prismaVersion && semver.gte(prismaVersion, '6.0.0') ? `${modelName}DefaultArgs` // Prisma 6+ removed [Model]Args type : `${modelName}Args`,packages/schema/src/cli/actions/init.ts (1)
82-92: Consider enhancing version parsing robustnessWhile the current implementation works for basic version patterns, it might not handle all semver cases.
Consider using a semver parsing library for more robust version handling:
function getLatestSupportedPrismaVersion() { - const versionSpec = pkgJson.peerDependencies.prisma; - let maxVersion: string | undefined; - const hyphen = versionSpec.indexOf('-'); - if (hyphen > 0) { - maxVersion = versionSpec.substring(hyphen + 1).trim(); - } else { - maxVersion = versionSpec; - } - return maxVersion ?? 'latest'; + const semver = require('semver'); + const versionSpec = pkgJson.peerDependencies.prisma; + const range = new semver.Range(versionSpec); + return range.range ? range.range : 'latest'; }packages/plugins/tanstack-query/src/runtime/vue.ts (1)
71-91: Well-structured reactive query options handling.The changes improve the Vue implementation by:
- Properly handling reactive options with
toValue- Computing queryKey separately for better organization
- Adding signal support for request cancellation
- Including queryKey in return value
However, there's a minor type improvement opportunity.
Consider adding the
ExtraQueryOptionstype to the computed return type for better type safety:-const queryOptions = computed<Omit<UseQueryOptions<TQueryFnData, TError, TData>, 'queryKey'>>(() => { +const queryOptions = computed<Omit<UseQueryOptions<TQueryFnData, TError, TData>, 'queryKey'> & ExtraQueryOptions>(() => {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (28)
package.jsonis excluded by!**/*.jsonpackages/ide/jetbrains/package.jsonis excluded by!**/*.jsonpackages/language/package.jsonis excluded by!**/*.jsonpackages/misc/redwood/package.jsonis excluded by!**/*.jsonpackages/plugins/openapi/package.jsonis excluded by!**/*.jsonpackages/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/swr/package.jsonis excluded by!**/*.jsonpackages/plugins/tanstack-query/package.jsonis excluded by!**/*.jsonpackages/plugins/trpc/package.jsonis excluded by!**/*.jsonpackages/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!**/*.jsonpackages/runtime/package.jsonis excluded by!**/*.jsonpackages/schema/package.jsonis excluded by!**/*.jsonpackages/schema/src/package.jsonis excluded by!**/*.jsonpackages/sdk/package.jsonis excluded by!**/*.jsonpackages/server/package.jsonis excluded by!**/*.jsonpackages/testtools/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!**/*.jsontests/integration/tsconfig.jsonis excluded by!**/*.json
📒 Files selected for processing (25)
packages/ide/jetbrains/build.gradle.kts(1 hunks)packages/plugins/openapi/tests/openapi-rpc.test.ts(5 hunks)packages/plugins/tanstack-query/src/runtime-v5/react.ts(4 hunks)packages/plugins/tanstack-query/src/runtime-v5/svelte.ts(6 hunks)packages/plugins/tanstack-query/src/runtime-v5/vue.ts(2 hunks)packages/plugins/tanstack-query/src/runtime/react.ts(2 hunks)packages/plugins/tanstack-query/src/runtime/svelte.ts(3 hunks)packages/plugins/tanstack-query/src/runtime/vue.ts(2 hunks)packages/plugins/tanstack-query/tests/plugin.test.ts(4 hunks)packages/schema/src/cli/actions/init.ts(3 hunks)packages/schema/src/language-server/validator/expression-validator.ts(0 hunks)packages/schema/src/plugins/enhancer/enhance/index.ts(4 hunks)packages/schema/src/plugins/prisma/schema-generator.ts(1 hunks)packages/schema/tests/schema/validation/datamodel-validation.test.ts(1 hunks)packages/sdk/src/code-gen.ts(1 hunks)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)packages/server/tests/api/rest.test.ts(5 hunks)packages/server/tests/api/rpc.test.ts(5 hunks)script/test-scaffold.ts(1 hunks)tests/integration/tests/cli/plugins.test.ts(2 hunks)tests/integration/tests/e2e/type-coverage.test.ts(1 hunks)tests/regression/tests/issue-1870.test.ts(1 hunks)tests/regression/tests/issue-1894.test.ts(1 hunks)
💤 Files with no reviewable changes (1)
- packages/schema/src/language-server/validator/expression-validator.ts
✅ Files skipped from review due to trivial changes (1)
- packages/sdk/src/code-gen.ts
🧰 Additional context used
🪛 Biome (1.9.4)
packages/schema/src/plugins/enhancer/enhance/index.ts
[error] 344-344: Use a regular expression literal instead of the RegExp constructor.
Regular expression literals avoid some escaping required in a string literal, and are easier to analyze statically.
Safe fix: Use a literal notation instead.
(lint/complexity/useRegexLiterals)
🔇 Additional comments (37)
packages/sdk/src/dmmf-helpers/include-helpers.ts (2)
1-1: Importing 'semver' module for version comparison is appropriate.
This allows the code to conditionally adjust behavior based on the Prisma version.
18-18: Prisma version retrieval added.
Initializing prismaVersion ensures that the code can adapt to different Prisma versions.
packages/sdk/src/dmmf-helpers/select-helpers.ts (3)
1-1: Importing 'semver' module for version comparison is appropriate.
This allows the code to adjust behavior based on the Prisma version.
64-64: Prisma version retrieval added.
Initializing prismaVersion enables version-based adjustments in the code.
99-99: Prisma version retrieval added for model select input types.
Initializing prismaVersion here ensures consistent version handling.
packages/schema/src/plugins/enhancer/enhance/index.ts (1)
343-343: 🛠️ Refactor suggestion
Use regex literal instead of the RegExp constructor for static patterns.
Using a regex literal improves readability and avoids unnecessary overhead.
Apply this diff to fix the issue:
-const createInputPattern = new RegExp(`^(.+?)(Unchecked)?Create.*Input$`);
+const createInputPattern = /^(.+?)(Unchecked)?Create.*Input$/;Likely invalid or redundant comment.
packages/schema/src/plugins/prisma/schema-generator.ts (1)
643-684: Logic for ensuring relations inherited from delegate models is correctly implemented.
The updated code properly handles the generation of relation attributes based on the presence of foreign key pairs and self-relations.
packages/server/tests/api/rest.test.ts (5)
2704-2704: Using 'Uint8Array' for binary data is appropriate.
This change ensures consistency in handling byte data across serialization and deserialization.
2739-2739: Assertion for 'Uint8Array' instance is correct.
Confirming that data.bytes is an instance of Uint8Array validates the data type correctly.
2747-2747: Using 'Uint8Array' for updated binary data is appropriate.
This maintains consistency when updating binary fields.
2794-2794: Assertion for 'Uint8Array' instance is correct.
Confirming that data.bytes remains an instance of Uint8Array after retrieval.
2810-2810: Verify that included attributes contain 'Uint8Array' instances.
Ensuring that related entities correctly handle binary data types.
script/test-scaffold.ts (1)
22-22: Verify compatibility with Prisma 6.0.x upgrade.
The upgrade from Prisma 5.22.x to 6.0.x is a major version bump that may include breaking changes.
Let's verify the upgrade impact:
✅ Verification successful
Prisma 6.0.x upgrade is consistently applied across the codebase
The verification shows that all Prisma-related dependencies across the repository are already aligned to version 6.0.x, including:
@prisma/clientandprismain test projects@prisma/generator-helperand@prisma/internalsin SDK packages@prisma/clientin schema packages
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for other Prisma-related dependencies that might need updates
rg -l "prisma|@prisma" --type json
# Check package.json files for version mismatches
for f in $(fd package.json); do
echo "=== $f ==="
jq '.dependencies,.devDependencies | with_entries(select(.key | contains("prisma")))' "$f"
done
Length of output: 7793
tests/regression/tests/issue-1894.test.ts (1)
26-28: Verify enhancement and compilation settings.
The test uses both 'delegate' enhancement and compilation. Ensure these settings are necessary and document their purpose.
✅ Verification successful
Based on the search results, I can now provide a verified response about the enhancement and compilation settings:
The enhancement and compilation settings are necessary for this test case.
The test is verifying a regression issue (#1894) that involves delegate enhancement functionality with model inheritance. The settings are justified because:
- The
delegateenhancement is required to test the@@delegateattribute functionality in the modelB compile: trueis needed because the test includes TypeScript code inextraSourceFilesthat needs to be compiled to verify the runtime behavior- This combination of settings is consistent with other similar regression tests in the codebase that test delegate enhancement functionality
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for other tests using similar settings
rg -B2 -A2 "enhancements.*delegate.*compile.*true" tests/
Length of output: 59
Script:
#!/bin/bash
# Let's try a broader search for delegate enhancement
rg -B3 -A3 "enhancements.*delegate" tests/
# Also search for compile settings
rg -B3 -A3 "compile:\s*true" tests/
# Let's also check the specific test file content
cat tests/regression/tests/issue-1894.test.ts
Length of output: 38608
tests/integration/tests/e2e/type-coverage.test.ts (1)
51-51: LGTM! Good improvement in using Uint8Array
The change from Buffer to Uint8Array is a good improvement as it:
- Uses a more standardized way to handle binary data
- Provides better cross-environment compatibility
- Maintains the same test coverage effectiveness
packages/sdk/src/dmmf-helpers/modelArgs-helpers.ts (1)
1-2: LGTM! Good implementation of version-based compatibility
The addition of version checking using semver provides a robust way to handle different Prisma versions.
Also applies to: 17-17
packages/ide/jetbrains/build.gradle.kts (1)
12-12: LGTM! Version bump for v2.10.0 release
The version update from 2.9.4 to 2.10.0 aligns with the PR objectives for the new release.
packages/schema/src/cli/actions/init.ts (1)
54-57: LGTM: Improved version handling for Prisma dependencies
The change from hardcoded 'latest' to dynamic version resolution is a good improvement that ensures better compatibility control.
packages/plugins/tanstack-query/src/runtime/react.ts (2)
67-78: LGTM: Enhanced query handling with cancellation support
Good improvements:
- Added signal support for request cancellation
- Included queryKey in return value for better debugging and cache management
- Maintained type safety with proper spreading of options
98-108: LGTM: Consistent infinite query implementation
The changes to infinite query handling mirror the regular query changes, maintaining consistency in the API.
packages/plugins/tanstack-query/src/runtime/svelte.ts (3)
13-13: LGTM: Added derived store import
Appropriate use of Svelte's derived store for reactive query results.
68-80: LGTM: Well-implemented query store with cancellation support
Good implementation:
- Proper use of derived store for combining queryKey with results
- Added signal support for request cancellation
- Maintains consistency with React implementation
100-110: LGTM: Consistent infinite query implementation
The infinite query implementation follows the same pattern as the regular query, ensuring API consistency across the codebase.
packages/plugins/tanstack-query/src/runtime-v5/svelte.ts (3)
2-2: LGTM: Import changes enhance type safety and improve code organization.
The changes to imports are well-structured:
- Adding
QueryKeytype improves type safety - Adding
QueryFunctiontype enhances function signature definitions - Reordering Svelte store imports maintains consistency
Also applies to: 12-12, 17-17
124-125: Consistent implementation of request cancellation in infinite queries.
The changes mirror the improvements made to useModelQuery:
- Adding abort signal support
- Including queryKey in the return value
This consistency across hooks is excellent for maintainability.
Also applies to: 152-156
76-77: Enhance request cancellation support and query key tracking.
The changes improve the hook's functionality by:
- Adding abort signal support for request cancellation
- Including queryKey in the return value for better debugging and cache management
Let's verify the queryKey usage in the codebase:
Also applies to: 98-102
✅ Verification successful
Based on the search results, I can now generate the final response:
Request cancellation and queryKey handling are properly implemented.
The code correctly:
- Implements request cancellation by passing the
signalparameter from the queryFn to the fetcher - Returns queryKey in the result object for proper cache management
- Follows the same pattern used across all framework implementations (React, Vue, Svelte)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for queryKey destructuring to ensure consistent usage
rg -A 2 '\bqueryKey\b.*=.*useModelQuery'
Length of output: 42
Script:
#!/bin/bash
# Let's search for queryKey usage in the codebase, particularly in tanstack-query related files
rg -A 5 '\bqueryKey\b' packages/plugins/tanstack-query/src/
# Also search for any query function definitions to understand the context
ast-grep --pattern 'const queryFn = $_'
Length of output: 42461
packages/plugins/tanstack-query/src/runtime/vue.ts (1)
118-132: 🛠️ Refactor suggestion
Consider removing the any type assertion.
The implementation is correct, but there's an opportunity to improve type safety.
Remove the any type assertion and properly type the computed options:
-const queryOptions: any = computed<
+const queryOptions = computed<
Omit<UseInfiniteQueryOptions<TQueryFnData, TError, InfiniteData<TData>>, 'queryKey' | 'initialPageParam'>
>(() => ({Likely invalid or redundant comment.
packages/plugins/tanstack-query/src/runtime-v5/vue.ts (1)
71-90: Clean implementation of v5 query options.
The changes properly implement TanStack Query v5 features:
- Correct handling of reactive options
- Proper implementation of the v5 query function signature
- Clean separation of queryKey computation
packages/plugins/tanstack-query/src/runtime-v5/react.ts (4)
71-82: LGTM: Enhanced query management with queryKey exposure
The changes properly implement React Query v5 patterns by:
- Computing and exposing queryKey for external cache management
- Supporting request cancellation via signal parameter
103-114: LGTM: Consistent implementation with useModelQuery
The changes maintain consistency with useModelQuery while properly handling suspense-specific functionality.
134-145: LGTM: Well-implemented infinite query support
The implementation correctly handles infinite query specifics while maintaining consistency with other hooks.
168-179: LGTM: Comprehensive implementation of suspense infinite queries
The implementation successfully combines suspense and infinite query functionality while maintaining consistency with other hooks.
tests/integration/tests/cli/plugins.test.ts (1)
78-78: Verify compatibility with Prisma 6.0.x upgrade
The upgrade from Prisma 5.22.x to 6.0.x is a major version change that might introduce breaking changes.
Also applies to: 88-88
✅ Verification successful
Based on the analysis of the test file and package.json files, I can now generate the final response:
Prisma 6.0.x upgrade is used only in tests and is compatible
The Prisma version upgrade from 5.22.x to 6.0.x in the test file is safe because:
- This is a test file that verifies plugin functionality with different package managers
- The project's package.json files show that Prisma 6.0.x is already supported as a peer dependency range (
"@prisma/client": "5.0.0 - 6.0.x") - The test is specifically designed to verify compatibility with supported Prisma versions
- No actual Prisma schema or database operations are performed in these tests
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for breaking changes in Prisma 6.0.x
# Search for Prisma-specific types and APIs that might need updates
rg -l "(?:Prisma|PrismaClient|prisma\.)" --type ts
# Look for migration guides or upgrade notes
fd -g "UPGRADE*.md" -g "MIGRATION*.md" -g "CHANGELOG*.md"
Length of output: 11138
Script:
#!/bin/bash
# Let's check the actual usage of Prisma in the test file and its dependencies
# First, check the specific test file content
cat tests/integration/tests/cli/plugins.test.ts
# Then look for any Prisma-related configuration or schema files
fd -g "schema.prisma"
# Check for package.json to understand the Prisma dependencies
fd -g "package.json" --exec cat {} \;
Length of output: 56511
packages/plugins/tanstack-query/tests/plugin.test.ts (1)
57-58: LGTM: Comprehensive test coverage for queryKey changes
The tests properly verify the queryKey exposure across React, Vue, and Svelte implementations, ensuring consistent behavior across frameworks.
Also applies to: 64-67, 149-150, 156-159, 225-226, 232-235
packages/server/tests/api/rpc.test.ts (1)
307-308: LGTM: Consistent use of Uint8Array for byte data handling.
The changes standardize the use of Uint8Array instead of Buffer for handling byte data in tests, which is a good practice as Uint8Array is more widely supported across different JavaScript environments.
Also applies to: 318-318, 320-320, 345-345, 348-348, 397-397, 421-421
packages/plugins/openapi/tests/openapi-rpc.test.ts (1)
461-489: LGTM: Comprehensive test coverage for auth().id default values.
The new test case properly verifies that fields with @default(auth().id) are correctly handled in the OpenAPI schema generation. It ensures that:
- The
authorfield is not required inPostCreateInput - The
authorIdfield is not required inPostCreateManyInput
This is important for maintaining correct API documentation when using authentication-based default values.
packages/schema/tests/schema/validation/datamodel-validation.test.ts (1)
78-78: LGTM: More precise error message for type incompatibility.
The error message has been updated from a specific message about unsupported types to a more general "incompatible operand types". This change makes the error message more accurate and consistent with type system validation.
No description provided.