merge dev to main (v3.0.0-beta.23) #406
Conversation
* fix(cli): improve compatibility for executing prisma commands * update
* fix(orm): allow `null` for select/include/omit * update
* fix(orm): select/include nullability * update * update * update
* fix(orm): reimplement typescript type display simplification * update
|
Warning Rate limit exceeded@ymc9 has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 8 minutes and 32 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (67)
✨ 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 |
|
Claude finished @ymc9's task —— View job PR Review: merge dev to main (v3.0.0-beta.23)Comprehensive review completed for this release preparation PR with 68 changed files. Todo List:
Review SummaryThis PR represents a solid release preparation with significant improvements to type safety, CLI utilities, and test coverage. The changes are well-structured and maintain backward compatibility while introducing valuable enhancements. 🟢 Strengths1. TypeScript Type System Improvements
2. CLI Enhancements
3. Comprehensive Test Coverage
4. Code Quality
🟡 Areas for Improvement1. Documentation
2. Error Handling
3. Performance Monitoring
🟢 Security Assessment
🟢 Performance Considerations
🟢 Test Coverage
Recommendation: ✅ APPROVEThis is a well-executed release preparation that:
The changes are ready for production deployment to v3.0.0-beta.23. Next Steps
|
There was a problem hiding this comment.
Pull Request Overview
This PR merges the dev branch to main for the v3.0.0-beta.23 release. It includes version bumps across all packages, significant type system improvements in the ORM layer, enhanced test utilities, and various code quality improvements.
Key Changes
- Version bump from 3.0.0-beta.22 to 3.0.0-beta.23 across all packages
- TypeScript schema generation now uses branded types to prevent compiler expansion
- ORM type system improvements: nullable select/include/omit fields, simplified type parameters
- Enhanced test utilities with file copying and PostgreSQL extension support
- CLI improvements for Prisma command execution and schema directory resolution
- Addition of Rally app test suite with comprehensive schema definitions
Reviewed Changes
Copilot reviewed 67 out of 68 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| package.json (multiple) | Version bumps to 3.0.0-beta.23 |
| packages/sdk/src/ts-schema-generator.ts | Implements branded schema types to prevent TypeScript type expansion |
| packages/sdk/src/prisma/prisma-schema-generator.ts | Adds default generator creation and enum schema handling |
| packages/orm/src/client/crud-types.ts | Simplifies type parameters, makes select/include/omit nullable, removes Schema parameter from filter types |
| packages/orm/src/client/crud/validator/index.ts | Updates validators to accept null for select/include/omit |
| packages/orm/src/client/executor/name-mapper.ts | Fixes join scope handling for proper table reference resolution |
| packages/testtools/src/client.ts | Adds copyFiles and dataSourceExtensions options |
| packages/cli/src/utils/exec-utils.ts | Adds execPrisma utility for direct Prisma CLI execution |
| packages/cli/src/actions/*.ts | Updates to use execPrisma and proper command escaping |
| tests/e2e/apps/rally/* | New comprehensive test app for Rally with full schema |
| tests/e2e/orm/schemas/* | Updated generated schema files with branded types |
| tests/e2e/orm/client-api/*.test.ts | Enhanced test coverage with enum fields |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Note Docstrings generation - SUCCESS |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/cli/src/utils/exec-utils.ts (1)
2-41: Remove unreachablerequire.resolvefallback and hardenexecPrismafor path safetyThe approach makes sense, but a couple of details need correction and improvement:
- Dead code: The package targets ESM exclusively (
"type": "module", tsconfig target"ESNext"). Theelsebranch withrequire.resolveis unreachable sincerequire()doesn't exist in ESM without a polyfill (and none is present). Remove it.- Shell path safety:
execSync(\node ${prismaPath} ${args}`, ...)runs via shell. IfprismaPathcontains spaces or shell metacharacters, the command fails or misbehaves. Useprocess.execPathand quote/escape the path, or switch toexecFileSync` with an argument array to avoid the shell.- Bare
'node': Relying on'node'onPATHis fragile.process.execPathis more robust for CLIs already running under Node.Simplified fix (removes dead code, improves path safety):
export function execPrisma( args: string, options?: Omit<ExecSyncOptions, 'env'> & { env?: Record<string, string> }, ) { - let prismaPath: string; - if (typeof import.meta.resolve === 'function') { - // esm - prismaPath = fileURLToPath(import.meta.resolve('prisma/build/index.js')); - } else { - // cjs - prismaPath = require.resolve('prisma/build/index.js'); - } - execSync(`node ${prismaPath} ${args}`, options); + const prismaPath = fileURLToPath(import.meta.resolve('prisma/build/index.js')); + const node = JSON.stringify(process.execPath); + const prisma = JSON.stringify(prismaPath); + execSync(`${node} ${prisma} ${args}`, options); }
🧹 Nitpick comments (6)
tests/e2e/apps/rally/rally.test.ts (1)
26-48: Consider strengthening test assertions.The test successfully exercises a complex query with filtering, sorting, and nested includes, but only asserts that the result is truthy. Consider adding more specific assertions to verify the query structure, returned fields, or data integrity, especially given this is establishing test infrastructure for the Rally app.
Example enhancement:
- ).toResolveTruthy(); + ).resolves.toEqual( + expect.objectContaining({ + userId: '1', + space: expect.objectContaining({ + id: expect.any(String), + name: expect.any(String), + }), + }) + );packages/cli/src/actions/migrate.ts (1)
4-4: Migration commands correctly switched toexecPrisma, but consider centralizing error handling and avoiding shell-string argsThe migrate subcommands (
dev,reset,deploy,status,resolve) now consistently buildmigrate ...command strings and invokeexecPrisma, with exit handling preserved viahandleSubProcessError. Behaviorally this aligns with the newexecPrismautility.Two refinements to consider:
Avoid shell-string interpolation for arguments
Building the command as a single interpolated string (
'migrate dev',--schema "...")means any spaces or special characters inprismaSchemaFile,options.name,options.applied, etc., rely on manual quoting and are more fragile (and easier to get wrong from a shell-injection perspective) than necessary. Long term, it would be safer to haveexecPrismaaccept an argument array and useexecFileSync/spawn-style APIs, so you can pass:['migrate', 'dev', '--schema', prismaSchemaFile, '--skip-generate', '--name', options.name]instead of a single string.
Reuse the shared
handleSubProcessErrorhelperThe local
handleSubProcessErrorimplementation at the bottom of this file duplicates the one inaction-utils.ts. Importing and using the shared version would reduce duplication and keep exit-code behavior consistent across actions. For example:-import { generateTempPrismaSchema, getSchemaFile } from './action-utils'; +import { generateTempPrismaSchema, getSchemaFile, handleSubProcessError } from './action-utils'; ... -function handleSubProcessError(err: unknown) { - if (err instanceof Error && 'status' in err && typeof err.status === 'number') { - process.exit(err.status); - } else { - process.exit(1); - } -}and then keep using
handleSubProcessError(err)in the catch blocks as you do now.These are non-blocking but would make the CLI surface more robust and maintainable.
Also applies to: 67-77, 82-103, 105-111, 113-129, 131-137
tests/e2e/apps/rally/zenstack/models/integrations.zmodel (1)
1-87: Integration models look coherent; double-check reused unique/index namesThe three new models (
Credential,CalendarConnection,ProviderCalendar) have consistent field types, timestamp conventions, relations toUser, and table/column mappings, which should play nicely with an existing schema.One thing to verify: both
CredentialandCalendarConnectiondefine the same composite-uniquename("user_provider_account_unique"), andProviderCalendardefines several named indexes. Depending on hownameis mapped to underlying constraint/index identifiers for your target database, reusing the same name across tables can cause migration/apply-time conflicts. Ifnameends up as a DB-level identifier, consider giving each constraint/index a table-specific name instead.tests/e2e/apps/rally/zenstack/models/space.zmodel (1)
1-73: Space domain models and mappings look well-structured
Space,SpaceMember, andSpaceMemberInviteare modeled coherently: IDs/defaults are consistent, mapped column and table names line up, relations (including cascades) match expected ownership semantics, and the composite uniques/indexes support common lookups (by owner, space/user pair, and invites). No structural issues stand out.tests/e2e/orm/schemas/name-mapping/schema.ts (1)
9-127: PK @Map additions and schema branding align with name-mapping goalsThe extra
@mapattributes onUser.id→user_idandPost.id→post_idplus the_schema/brandedSchemaexport look correct and consistent with other fixtures. This should give better coverage for PK-level name mapping without changing logical field identities used by the ORM.If you want stricter coverage of mapped-name behavior, consider adding/adjusting e2e assertions to explicitly exercise queries filtering and ordering by these mapped PKs, especially when inherited via typedefs, as noted previously. Based on learnings
packages/orm/src/client/crud/dialects/base-dialect.ts (1)
607-721: Filter helper generic updates and bytes-filter fix look correctThe updated signatures for
buildStringFilter,buildBooleanFilter,buildDateTimeFilter, andbuildBytesFiltermatch the newStringFilter/BooleanFilter/DateTimeFilter/BytesFilter<Nullable, WithAggregations>definitions and keep recursion well-typed via the narrowed casts.The change in
buildBytesFilterto returnthis.and(...conditions.conditions)fixes the previous mismatch withbuildStandardFilter’s{ conditions, consumedKeys }shape and aligns it withbuildEnumFilter.For readability, you might optionally destructure in
buildBytesFilter(e.g.,const { conditions } = this.buildStandardFilter(...)) to matchbuildNumberFilterand avoid the slightly awkwardconditions.conditionsaccess.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (67)
-
package.json(1 hunks) -
packages/cli/package.json(1 hunks) -
packages/cli/src/actions/action-utils.ts(1 hunks) -
packages/cli/src/actions/db.ts(2 hunks) -
packages/cli/src/actions/migrate.ts(2 hunks) -
packages/cli/src/utils/exec-utils.ts(2 hunks) -
packages/cli/test/generate.test.ts(1 hunks) -
packages/cli/test/migrate.test.ts(1 hunks) -
packages/clients/tanstack-query/package.json(1 hunks) -
packages/clients/tanstack-query/src/react.ts(1 hunks) -
packages/clients/tanstack-query/src/svelte.ts(1 hunks) -
packages/clients/tanstack-query/src/vue.ts(1 hunks) -
packages/clients/tanstack-query/test/schemas/basic/schema-lite.ts(2 hunks) -
packages/common-helpers/package.json(1 hunks) -
packages/config/eslint-config/package.json(1 hunks) -
packages/config/typescript-config/package.json(1 hunks) -
packages/config/vitest-config/package.json(1 hunks) -
packages/create-zenstack/package.json(1 hunks) -
packages/dialects/sql.js/package.json(1 hunks) -
packages/language/package.json(1 hunks) -
packages/orm/package.json(1 hunks) -
packages/orm/src/client/contract.ts(17 hunks) -
packages/orm/src/client/crud-types.ts(9 hunks) -
packages/orm/src/client/crud/dialects/base-dialect.ts(4 hunks) -
packages/orm/src/client/crud/operations/create.ts(1 hunks) -
packages/orm/src/client/crud/operations/update.ts(1 hunks) -
packages/orm/src/client/crud/validator/index.ts(8 hunks) -
packages/orm/src/client/executor/name-mapper.ts(1 hunks) -
packages/plugins/policy/package.json(1 hunks) -
packages/schema/package.json(1 hunks) -
packages/sdk/package.json(1 hunks) -
packages/sdk/src/prisma/prisma-schema-generator.ts(4 hunks) -
packages/sdk/src/ts-schema-generator.ts(2 hunks) -
packages/server/package.json(1 hunks) -
packages/testtools/package.json(1 hunks) -
packages/testtools/src/client.ts(4 hunks) -
packages/zod/package.json(1 hunks) -
samples/next.js/package.json(1 hunks) -
samples/next.js/zenstack/schema-lite.ts(2 hunks) -
samples/next.js/zenstack/schema.ts(2 hunks) -
samples/orm/package.json(1 hunks) -
samples/orm/zenstack/schema.ts(2 hunks) -
tests/e2e/apps/rally/rally.test.ts(1 hunks) -
tests/e2e/apps/rally/zenstack/input.ts(1 hunks) -
tests/e2e/apps/rally/zenstack/models.ts(1 hunks) -
tests/e2e/apps/rally/zenstack/models/billing.zmodel(1 hunks) -
tests/e2e/apps/rally/zenstack/models/event.zmodel(1 hunks) -
tests/e2e/apps/rally/zenstack/models/instance-settings.zmodel(1 hunks) -
tests/e2e/apps/rally/zenstack/models/integrations.zmodel(1 hunks) -
tests/e2e/apps/rally/zenstack/models/licensing.zmodel(1 hunks) -
tests/e2e/apps/rally/zenstack/models/poll.zmodel(1 hunks) -
tests/e2e/apps/rally/zenstack/models/space.zmodel(1 hunks) -
tests/e2e/apps/rally/zenstack/models/user.zmodel(1 hunks) -
tests/e2e/apps/rally/zenstack/schema.zmodel(1 hunks) -
tests/e2e/orm/client-api/name-mapping.test.ts(2 hunks) -
tests/e2e/orm/client-api/pg-custom-schema.test.ts(8 hunks) -
tests/e2e/orm/schemas/basic/schema.ts(2 hunks) -
tests/e2e/orm/schemas/default-auth/schema.ts(2 hunks) -
tests/e2e/orm/schemas/delegate/schema.ts(2 hunks) -
tests/e2e/orm/schemas/name-mapping/schema.ts(4 hunks) -
tests/e2e/orm/schemas/name-mapping/schema.zmodel(1 hunks) -
tests/e2e/orm/schemas/petstore/schema.ts(2 hunks) -
tests/e2e/orm/schemas/todo/schema.ts(2 hunks) -
tests/e2e/orm/schemas/typing/schema.ts(2 hunks) -
tests/e2e/package.json(1 hunks) -
tests/e2e/scripts/generate.ts(2 hunks) -
tests/regression/package.json(1 hunks)
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-10-21T16:09:31.218Z
Learnt from: ymc9
Repo: zenstackhq/zenstack-v3 PR: 319
File: packages/runtime/src/client/executor/zenstack-query-executor.ts:63-72
Timestamp: 2025-10-21T16:09:31.218Z
Learning: In ZenStack, TypeDefs can be inherited by models. When a TypeDef contains fields with `map` attributes, those mapped field names need to be processed by the QueryNameMapper since they become part of the inheriting model's schema. Therefore, when checking if a schema has mapped names (e.g., in `schemaHasMappedNames`), both `schema.models` and `schema.typeDefs` must be inspected for `@map` and `map` attributes.
Applied to files:
tests/e2e/apps/rally/zenstack/models/licensing.zmodeltests/e2e/apps/rally/zenstack/models/integrations.zmodeltests/e2e/apps/rally/zenstack/schema.zmodeltests/e2e/orm/schemas/name-mapping/schema.tssamples/next.js/zenstack/schema.tssamples/orm/zenstack/schema.tstests/e2e/apps/rally/zenstack/models/user.zmodeltests/e2e/apps/rally/zenstack/input.tssamples/next.js/zenstack/schema-lite.tstests/e2e/orm/schemas/name-mapping/schema.zmodeltests/e2e/apps/rally/zenstack/models.ts
📚 Learning: 2025-10-21T16:04:56.292Z
Learnt from: ymc9
Repo: zenstackhq/zenstack-v3 PR: 319
File: packages/runtime/src/client/crud/dialects/base-dialect.ts:745-747
Timestamp: 2025-10-21T16:04:56.292Z
Learning: In packages/runtime/src/client/crud/dialects/base-dialect.ts, it's intentional that buildCursorFilter applies default ordering (via makeDefaultOrderBy fallback) while buildOrderBy does not. This ensures cursor-based pagination always has stable ordering for correctness, while regular queries remain unordered unless explicitly specified. This design is to be consistent with Prisma's pagination requirements.
Applied to files:
packages/orm/src/client/crud/dialects/base-dialect.tspackages/orm/src/client/crud-types.ts
🧬 Code graph analysis (26)
packages/cli/src/actions/action-utils.ts (1)
packages/cli/src/cli-error.ts (1)
CliError(4-4)
tests/e2e/orm/schemas/basic/schema.ts (2)
packages/clients/tanstack-query/test/schemas/basic/schema-lite.ts (2)
schema(175-175)SchemaType(176-176)packages/orm/src/client/crud/validator/index.ts (1)
schema(60-62)
tests/e2e/orm/schemas/default-auth/schema.ts (5)
packages/clients/tanstack-query/test/schemas/basic/schema-lite.ts (2)
schema(175-175)SchemaType(176-176)samples/next.js/zenstack/schema-lite.ts (2)
schema(109-109)SchemaType(110-110)tests/e2e/orm/schemas/basic/schema.ts (2)
schema(290-290)SchemaType(291-291)tests/e2e/orm/schemas/delegate/schema.ts (2)
schema(468-468)SchemaType(469-469)tests/e2e/apps/rally/zenstack/schema.ts (2)
schema(2526-2526)SchemaType(2527-2527)
packages/orm/src/client/crud/operations/create.ts (1)
packages/orm/src/client/query-utils.ts (1)
getIdValues(173-179)
packages/orm/src/client/crud/operations/update.ts (1)
packages/orm/src/client/query-utils.ts (1)
getIdValues(173-179)
tests/e2e/orm/schemas/petstore/schema.ts (13)
packages/clients/tanstack-query/test/schemas/basic/schema-lite.ts (2)
schema(175-175)SchemaType(176-176)samples/next.js/zenstack/schema-lite.ts (2)
schema(109-109)SchemaType(110-110)samples/next.js/zenstack/schema.ts (2)
schema(118-118)SchemaType(119-119)samples/orm/zenstack/schema.ts (2)
schema(247-247)SchemaType(248-248)tests/e2e/orm/schemas/basic/schema.ts (2)
schema(290-290)SchemaType(291-291)tests/e2e/orm/schemas/default-auth/schema.ts (2)
schema(125-125)SchemaType(126-126)tests/e2e/orm/schemas/delegate/schema.ts (2)
schema(468-468)SchemaType(469-469)tests/e2e/orm/schemas/name-mapping/schema.ts (2)
schema(126-126)SchemaType(127-127)tests/e2e/orm/schemas/todo/schema.ts (2)
schema(399-399)SchemaType(400-400)tests/e2e/orm/schemas/typing/schema.ts (2)
schema(350-350)SchemaType(351-351)packages/orm/src/client/crud/validator/index.ts (1)
schema(60-62)tests/e2e/apps/rally/zenstack/schema.ts (2)
schema(2526-2526)SchemaType(2527-2527)packages/plugins/policy/src/expression-transformer.ts (1)
schema(81-83)
packages/cli/src/actions/db.ts (1)
packages/cli/src/utils/exec-utils.ts (1)
execPrisma(32-42)
tests/e2e/apps/rally/rally.test.ts (3)
packages/orm/src/client/contract.ts (1)
ClientContract(52-172)tests/e2e/apps/rally/zenstack/schema.ts (2)
SchemaType(2527-2527)schema(2526-2526)packages/testtools/src/client.ts (1)
createTestClient(95-244)
packages/orm/src/client/crud/dialects/base-dialect.ts (1)
packages/orm/src/client/crud-types.ts (4)
StringFilter(306-322)BooleanFilter(367-378)DateTimeFilter(341-350)BytesFilter(352-365)
tests/e2e/orm/schemas/name-mapping/schema.ts (13)
packages/clients/tanstack-query/test/schemas/basic/schema-lite.ts (2)
schema(175-175)SchemaType(176-176)samples/next.js/zenstack/schema-lite.ts (2)
schema(109-109)SchemaType(110-110)samples/next.js/zenstack/schema.ts (2)
schema(118-118)SchemaType(119-119)samples/orm/zenstack/schema.ts (2)
schema(247-247)SchemaType(248-248)tests/e2e/orm/schemas/basic/schema.ts (2)
schema(290-290)SchemaType(291-291)tests/e2e/orm/schemas/default-auth/schema.ts (2)
schema(125-125)SchemaType(126-126)tests/e2e/orm/schemas/delegate/schema.ts (2)
schema(468-468)SchemaType(469-469)tests/e2e/orm/schemas/petstore/schema.ts (2)
schema(160-160)SchemaType(161-161)tests/e2e/orm/schemas/todo/schema.ts (2)
schema(399-399)SchemaType(400-400)tests/e2e/orm/schemas/typing/schema.ts (2)
schema(350-350)SchemaType(351-351)packages/orm/src/client/crud/validator/index.ts (1)
schema(60-62)tests/e2e/apps/rally/zenstack/schema.ts (2)
schema(2526-2526)SchemaType(2527-2527)packages/plugins/policy/src/expression-transformer.ts (1)
schema(81-83)
samples/next.js/zenstack/schema.ts (11)
packages/clients/tanstack-query/test/schemas/basic/schema-lite.ts (2)
schema(175-175)SchemaType(176-176)samples/next.js/zenstack/schema-lite.ts (2)
schema(109-109)SchemaType(110-110)samples/orm/zenstack/schema.ts (2)
schema(247-247)SchemaType(248-248)tests/e2e/orm/schemas/basic/schema.ts (2)
schema(290-290)SchemaType(291-291)tests/e2e/orm/schemas/default-auth/schema.ts (2)
schema(125-125)SchemaType(126-126)tests/e2e/orm/schemas/delegate/schema.ts (2)
schema(468-468)SchemaType(469-469)tests/e2e/orm/schemas/name-mapping/schema.ts (2)
schema(126-126)SchemaType(127-127)tests/e2e/orm/schemas/petstore/schema.ts (2)
schema(160-160)SchemaType(161-161)tests/e2e/orm/schemas/todo/schema.ts (2)
schema(399-399)SchemaType(400-400)tests/e2e/orm/schemas/typing/schema.ts (2)
schema(350-350)SchemaType(351-351)tests/e2e/apps/rally/zenstack/schema.ts (2)
schema(2526-2526)SchemaType(2527-2527)
packages/cli/test/generate.test.ts (1)
packages/cli/test/utils.ts (2)
createProject(12-18)runCli(20-23)
packages/clients/tanstack-query/src/vue.ts (1)
packages/orm/src/client/crud-types.ts (19)
FindUniqueArgs(666-668)SelectSubset(505-511)SimplifiedModelResult(181-187)FindFirstArgs(664-664)FindManyArgs(662-662)CreateArgs(674-676)CreateManyArgs(678-678)BatchResult(201-201)CreateManyAndReturnArgs(680-684)UpdateArgs(810-813)UpdateManyArgs(815-818)UpdateManyAndReturnArgs(820-824)UpsertArgs(832-836)DeleteArgs(948-950)DeleteManyArgs(952-955)CountArgs(961-966)Subset(501-503)AggregateArgs(986-1000)GroupByArgs(1071-1088)
tests/e2e/orm/schemas/typing/schema.ts (2)
packages/orm/src/client/crud/validator/index.ts (1)
schema(60-62)packages/plugins/policy/src/expression-transformer.ts (1)
schema(81-83)
packages/clients/tanstack-query/test/schemas/basic/schema-lite.ts (1)
samples/next.js/zenstack/schema-lite.ts (2)
schema(109-109)SchemaType(110-110)
samples/orm/zenstack/schema.ts (2)
packages/clients/tanstack-query/test/schemas/basic/schema-lite.ts (2)
schema(175-175)SchemaType(176-176)packages/orm/src/client/crud/validator/index.ts (1)
schema(60-62)
packages/sdk/src/prisma/prisma-schema-generator.ts (2)
packages/language/src/generated/ast.ts (2)
isGeneratorDecl(516-518)isDataSource(417-419)packages/sdk/src/prisma/prisma-builder.ts (1)
PrismaModel(11-52)
packages/orm/src/client/contract.ts (1)
packages/orm/src/client/crud-types.ts (15)
FindManyArgs(662-662)FindUniqueArgs(666-668)FindFirstArgs(664-664)CreateArgs(674-676)CreateManyArgs(678-678)CreateManyAndReturnArgs(680-684)UpdateArgs(810-813)UpdateManyArgs(815-818)UpdateManyAndReturnArgs(820-824)UpsertArgs(832-836)DeleteArgs(948-950)DeleteManyArgs(952-955)CountArgs(961-966)AggregateArgs(986-1000)GroupByArgs(1071-1088)
samples/next.js/zenstack/schema-lite.ts (4)
packages/clients/tanstack-query/test/schemas/basic/schema-lite.ts (2)
schema(175-175)SchemaType(176-176)samples/next.js/zenstack/schema.ts (2)
schema(118-118)SchemaType(119-119)samples/orm/zenstack/schema.ts (2)
schema(247-247)SchemaType(248-248)tests/e2e/orm/schemas/basic/schema.ts (2)
schema(290-290)SchemaType(291-291)
tests/e2e/orm/schemas/todo/schema.ts (3)
packages/clients/tanstack-query/test/schemas/basic/schema-lite.ts (2)
schema(175-175)SchemaType(176-176)packages/orm/src/client/crud/validator/index.ts (1)
schema(60-62)packages/plugins/policy/src/expression-transformer.ts (1)
schema(81-83)
packages/clients/tanstack-query/src/react.ts (1)
packages/orm/src/client/crud-types.ts (19)
FindUniqueArgs(666-668)SelectSubset(505-511)SimplifiedModelResult(181-187)FindFirstArgs(664-664)FindManyArgs(662-662)CreateArgs(674-676)CreateManyArgs(678-678)CreateManyAndReturnArgs(680-684)UpdateArgs(810-813)UpdateManyArgs(815-818)UpdateManyAndReturnArgs(820-824)UpsertArgs(832-836)DeleteArgs(948-950)DeleteManyArgs(952-955)CountArgs(961-966)Subset(501-503)AggregateArgs(986-1000)GroupByArgs(1071-1088)GroupByResult(1090-1124)
packages/cli/src/actions/migrate.ts (3)
packages/cli/src/utils/exec-utils.ts (1)
execPrisma(32-42)packages/cli/src/actions/action-utils.ts (1)
handleSubProcessError(58-64)packages/cli/src/cli-error.ts (1)
CliError(4-4)
packages/clients/tanstack-query/src/svelte.ts (1)
packages/orm/src/client/crud-types.ts (21)
FindUniqueArgs(666-668)SelectSubset(505-511)SimplifiedModelResult(181-187)FindFirstArgs(664-664)FindManyArgs(662-662)CreateArgs(674-676)CreateManyArgs(678-678)BatchResult(201-201)CreateManyAndReturnArgs(680-684)UpdateArgs(810-813)UpdateManyArgs(815-818)UpdateManyAndReturnArgs(820-824)UpsertArgs(832-836)DeleteArgs(948-950)DeleteManyArgs(952-955)CountArgs(961-966)Subset(501-503)CountResult(972-980)AggregateArgs(986-1000)AggregateResult(1026-1052)GroupByArgs(1071-1088)
packages/orm/src/client/crud-types.ts (2)
packages/orm/src/utils/type-utils.ts (3)
NullableIf(5-5)OrArray(52-52)NonEmptyArray(54-54)packages/schema/src/schema.ts (3)
SchemaDef(11-19)GetModels(120-120)NonRelationFields(204-208)
packages/testtools/src/client.ts (2)
packages/common-helpers/src/tiny-invariant.ts (1)
invariant(4-14)packages/orm/src/client/options.ts (1)
ClientOptions(45-96)
tests/e2e/orm/schemas/delegate/schema.ts (3)
packages/clients/tanstack-query/test/schemas/basic/schema-lite.ts (2)
schema(175-175)SchemaType(176-176)packages/orm/src/client/crud/validator/index.ts (1)
schema(60-62)packages/plugins/policy/src/expression-transformer.ts (1)
schema(81-83)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: Upload results
- GitHub Check: build-test (20.x, sqlite)
- GitHub Check: build-test (20.x, postgresql)
- GitHub Check: claude-review
🔇 Additional comments (77)
packages/clients/tanstack-query/test/schemas/basic/schema-lite.ts (3)
9-171: LGTM! Internal schema constant correctly defined.The refactoring to make this an internal
_schemaconstant (rather than a direct export) is correctly implemented as part of the branded type pattern. The schema definition usesas const satisfies SchemaDefwhich provides both type validation and literal type preservation.
172-174: Branded type pattern correctly implemented.The branded type definition using an optional
__brandproperty is a valid approach that provides type-level distinction without runtime overhead. This pattern allows the internal_schemaconstant to be assigned to the publicSchematype while maintaining nominal typing for better type safety.
175-176: Public exports correctly implement branded type pattern.The schema export and type alias correctly apply the branded type pattern to the public API. The assignment of
_schemato theSchema-typed constant is valid, and theSchemaTypealias provides a convenient way to reference this type throughout the codebase.tests/e2e/scripts/generate.ts (1)
11-14: Glob patterns verified—no issues found.The expanded schema discovery resolves correctly. Both
../orm/schemas/**/*.zmodeland../apps/**/schema.zmodelpatterns find expected files in the repository structure.packages/sdk/src/prisma/prisma-schema-generator.ts (3)
23-23: LGTM!The
isGeneratorDeclimport is correctly added to support the new default generator logic.
110-112: LGTM!The default generator fallback ensures valid Prisma schemas are always generated when no explicit generator is declared.
419-435: LGTM!The refactoring ensures enums receive the same default
@@schemaattribute injection as models, maintaining consistency across container types when the datasource declares multiple schemas.packages/testtools/src/client.ts (3)
8-8: LGTM! Clean API design for the copyFiles feature.The glob import and
copyFilesoption provide a flexible way to copy additional test fixtures and assets into the working directory.Also applies to: 84-84
150-158: LGTM! Improved options handling and debug integration.The destructuring cleanly separates plugin handling, and integrating the test logger into client options when debug mode is enabled will help with troubleshooting test failures.
140-140: The Prisma datasource extensions syntax uses unquoted identifiers in the formatextensions = [<extension1>, <extension2(arg: "value")>, ...]. The code at line 140 correctly renders extensions without quotes, matching the documented syntax.packages/orm/src/client/crud/validator/index.ts (3)
748-759: Consistent nullable pattern applied to nested relation schemas.The nullable modification is correctly applied to nested relation select/include/omit schemas, maintaining consistency with the top-level changes. The use of
z.lazy()for circular references is preserved.
269-271: Add test coverage for null values in select/include/omit fields before merging.The change adding
.nullable()is intentionally applied across all schema builders. The mutual exclusivity refinements correctly handle null values—null && valueevaluates to falsy, allowing null to bypass checks just like undefined. This is technically correct behavior.However, no test coverage exists for null value scenarios in any test files found. Before merging, verify:
- That explicitly passing
nullfor these fields is an intentional API design choice (not an unintended side effect).- Add test cases covering:
{ select: null }alone{ select: null, include: {...} }to confirm no mutual exclusivity error{ select: null, omit: {...} }to confirm no mutual exclusivity error
1508-1520: The mutual exclusivity logic is correct.The refinement methods properly implement mutual exclusivity validation. With fields defined as
.optional().nullable(), the logic correctly treatsnullandundefinedas "not set" values:
!(value['select'] && value['include'])passes when either field is falsy (null/undefined)- Fails only when both fields contain actual objects (both explicitly set)
This semantics aligns with the ORM API design where select/include/omit are genuinely optional parameters. The pattern is consistently applied throughout all schema definitions in the codebase.
packages/language/package.json (1)
4-4: Version bump to beta.23 is appropriate.Consistent with the PR objective to release v3.0.0-beta.23.
packages/zod/package.json (1)
3-3: Version bump to beta.23 is consistent across the monorepo.packages/testtools/package.json (1)
3-3: Version bump is consistent and correct.packages/server/package.json (1)
3-3: Version bump is appropriate and consistent.samples/next.js/package.json (1)
3-3: Version bump is correct.samples/orm/package.json (1)
3-3: Version bump is consistent and correct.packages/common-helpers/package.json (1)
3-3: Version bump is consistent across the monorepo.packages/schema/package.json (1)
3-3: Version bump incomplete — VSCode IDE package not updated.Verification found that most packages were correctly updated to
3.0.0-beta.23, butpackages/ide/vscode/package.jsonretains version3.0.12.Confirm whether the VSCode plugin intentionally uses independent versioning, or if this file requires updating to
3.0.0-beta.23to match the rest of the monorepo.packages/sdk/package.json (1)
3-3: Version bump to 3.0.0-beta.23.Metadata-only update aligns with global version increment across the monorepo.
packages/config/eslint-config/package.json (1)
3-3: Version bump to 3.0.0-beta.23.Metadata-only update aligns with global version increment across the monorepo.
packages/orm/package.json (1)
3-3: Version bump to 3.0.0-beta.23.Metadata-only update aligns with global version increment across the monorepo.
packages/cli/package.json (1)
6-6: Version bump to 3.0.0-beta.23.Metadata-only update aligns with global version increment across the monorepo.
package.json (1)
3-3: Version bump to 3.0.0-beta.23.Metadata-only update aligns with global version increment across the monorepo.
packages/clients/tanstack-query/package.json (1)
3-3: Version bump to 3.0.0-beta.23.Metadata-only update aligns with global version increment across the monorepo.
packages/config/vitest-config/package.json (1)
4-4: Version bump to 3.0.0-beta.23.Metadata-only update aligns with global version increment across the monorepo.
tests/e2e/package.json (2)
3-3: Version bump to 3.0.0-beta.23.Metadata-only update aligns with global version increment across the monorepo.
8-8: Path reorganization verified and complete.The test generation script has been successfully moved from
orm/scripts/generate.tstoscripts/generate.ts. The new script exists at the expected location, the old path has been removed, and there are no remaining references to the deprecated path in the codebase.tests/regression/package.json (1)
3-3: LGTM! Version bump for coordinated beta.23 release.The version bump is part of the repository-wide release cycle to 3.0.0-beta.23.
packages/plugins/policy/package.json (1)
3-3: LGTM! Version bump for coordinated beta.23 release.packages/dialects/sql.js/package.json (1)
3-3: LGTM! Version bump for coordinated beta.23 release.samples/next.js/zenstack/schema-lite.ts (1)
9-110: LGTM! Schema refactored with branded type pattern.The migration to a branded
Schematype (with internal_schemaconstant) aligns with the broader repository pattern seen across multiple schema files. This improves type safety while maintaining the same runtime behavior.packages/config/typescript-config/package.json (1)
3-3: LGTM! Version bump for coordinated beta.23 release.packages/create-zenstack/package.json (1)
3-3: LGTM! Version bump for coordinated beta.23 release.packages/cli/src/actions/action-utils.ts (1)
22-30: LGTM! Directory-based schema resolution implemented correctly.The logic properly handles the new directory-based schema configuration:
- Checks if the path is a directory
- Appends
schema.zmodeland validates its existence- Falls back to file-based handling for backward compatibility
The implementation is covered by the new test in
packages/cli/test/generate.test.ts.packages/cli/test/generate.test.ts (1)
48-61: LGTM! Test coverage for directory-based schema resolution.The test properly validates the new directory-based schema configuration feature by:
- Setting
zenstack.schemato a directory path ('./foo') instead of a file path- Verifying that the CLI correctly resolves to
foo/schema.zmodel- Confirming the output is generated in the expected location
This complements the existing file-based schema test and provides good coverage for the new feature.
samples/orm/zenstack/schema.ts (1)
9-248: Branded schema export pattern looks consistent and safeSwitching to an internal
_schemaplus a brandedSchematype and re-exportingschema: Schema/SchemaType = Schemakeeps runtime behavior identical while tightening the public typings and preventing unwanted type expansion in consumers. This matches the pattern used in other generated schemas and looks good.packages/sdk/src/ts-schema-generator.ts (1)
151-215: Schema generator’s branded type emission is coherent with consumersThe generator now emits:
const _schema = { ... } as const satisfies SchemaDef;- a non-exported branded
type Schema = typeof _schema & { __brand?: 'schema' };export const schema: Schema = _schema;export type SchemaType = Schema;This matches how sample/generated schemas are structured and keeps downstream imports (
schemaandSchemaType) inmodels.tsandinput.tsconsistent. The use ofcreateSatisfiesExpression(createAsExpression(..., 'const'), 'SchemaDef')correctly modelsas const satisfies SchemaDef. No issues from a type- or generator-logic perspective.packages/clients/tanstack-query/src/react.ts (1)
148-252: Hook generic constraints now align with updated ORM arg typesThe hook signatures now use
T extends XxxArgs<Schema, Model>(e.g.FindManyArgs,CreateArgs,CountArgs,GroupByArgs) and plugTintoSelectSubset/SubsetandSimplifiedModelResultconsistently across all operations. This matches the current@zenstackhq/ormarg type aliases and keeps the query/mutation result typing coherent. No issues here.packages/cli/test/migrate.test.ts (1)
12-72: Re-enabling migrate CLI integration tests is beneficialSwitching back to
describe('CLI migrate commands test', ...)ensures the Prisma-backed migrate and db commands are exercised end-to-end (dev/reset/deploy/status/resolve) against a real project layout. The test logic itself looks sound for an integration suite.packages/cli/src/actions/db.ts (1)
2-2: LGTM! Consistent refactor to new Prisma execution utility.The changes correctly adopt the new
execPrismahelper, which handles Prisma command execution via Node with proper esm/cjs resolution. The import, command string (dropping the "prisma" prefix), and function call are all updated consistently.Also applies to: 30-30, 38-38
packages/orm/src/client/crud/operations/create.ts (1)
81-91: LGTM! Improved readability with multi-line formatting.The read-back invocation has been reformatted to multi-line for better clarity. The arguments and logic remain unchanged, and the existing
as anycast with the TODO comment is preserved for future type refinement.packages/orm/src/client/executor/name-mapper.ts (1)
80-84: LGTM! Critical enhancement for join condition resolution.The join clause processing now correctly executes within a scope that includes all available "from" scopes, enabling join conditions to reference from-table aliases. This is essential for proper name resolution when join conditions reference tables from the FROM clause.
packages/orm/src/client/crud/operations/update.ts (1)
107-117: LGTM! Consistent multi-line formatting improvement.The read-back invocation has been reformatted to match the pattern in create.ts, improving readability. The logic remains unchanged, and the existing
as anycast with the TODO comment is preserved for future type work.tests/e2e/orm/schemas/name-mapping/schema.zmodel (1)
14-14: LGTM! Enhanced name mapping test coverage.Adding
@mapattributes to primary key fields strengthens the name mapping test scenarios, ensuring the ORM correctly handles mapped identifiers in all CRUD operations and join conditions.Also applies to: 22-22
tests/e2e/orm/client-api/pg-custom-schema.test.ts (1)
41-50: LGTM! Comprehensive test coverage for enum fields in custom schemas.The tests consistently add Role enum fields across multiple PostgreSQL custom schema scenarios, verifying that enum handling works correctly with different schema configurations. The updates include proper model definitions, create operations with role values, and appropriate error message adjustments.
Also applies to: 66-68, 86-95, 102-104, 115-124, 131-131, 146-156, 159-169, 187-188, 263-272, 295-295
tests/e2e/orm/client-api/name-mapping.test.ts (2)
160-167: LGTM! Strong test coverage for nested includes with filtering.The new test validates that name mapping works correctly with nested includes and where clauses, ensuring the ORM properly handles field name resolution in complex relational queries. The assertion appropriately verifies both the structure and content of the returned data.
211-221: LGTM! Validates alternative join syntax with name mapping.This test verifies that the
onRefcallback syntax for joins works correctly with name mapping. It complements the existingwhereRefjoin test (lines 199-209) by exercising the same scenario with different syntax, ensuring both join patterns are supported.tests/e2e/orm/schemas/todo/schema.ts (1)
9-9: BrandedSchemaexport pattern looks consistentUsing an internal
_schemaplus a brandedSchematype and exportingschema: Schema/SchemaType = Schemacleanly separates runtime data from its public typing and matches the pattern used elsewhere. No issues spotted.Also applies to: 396-400
tests/e2e/orm/schemas/delegate/schema.ts (1)
9-9: Schema branding matches the new conventionsInternal
_schemaplus brandedSchemaandSchemaTypekeeps runtime unchanged while tightening typings, and is consistent with other schema files in this PR. Looks good.Also applies to: 465-469
tests/e2e/orm/schemas/basic/schema.ts (1)
9-9: Basic schema branding aligns with the new schema typing patternUsing
_schemaplus a brandedSchemaand exportingschema: Schema/SchemaType = Schemais consistent with the other updated schemas and keeps the runtime data intact. No issues found.Also applies to: 287-291
samples/next.js/zenstack/schema.ts (1)
9-119: BrandedSchemaexport pattern looks consistent and type-safeUsing an internal
_schemawithas const satisfies SchemaDef, then exporting a brandedSchemaviaexport const schema: Schema = _schema;andexport type SchemaType = Schema;aligns with the pattern used elsewhere and should preserve both runtime shape and stronger typing.tests/e2e/orm/schemas/default-auth/schema.ts (1)
9-126: Default-auth schema branding matches new typing patternThe refactor to
_schemaplus the brandedSchematype, withexport const schema: Schema = _schema;andexport type SchemaType = Schema;, is consistent with the other schema files and keeps the runtime schema unchanged.tests/e2e/orm/schemas/typing/schema.ts (1)
9-351: Typing schema export refactor is coherent with brandedSchemadesignIntroducing
_schemaand exportingschema: Schema = _schemaplusSchemaType = Schemacleanly wraps the existing schema with the new branded type without altering its structure, matching the broader refactor across the repo.tests/e2e/orm/schemas/petstore/schema.ts (1)
9-161: Branded schema export pattern looks consistent and type-safeThe introduction of
_schema, brandedSchema, andSchemaType = Schemamatches the new standard used elsewhere and keeps the runtime value and type aligned while remaining assignable toSchemaDef. No issues spotted in this file.tests/e2e/apps/rally/zenstack/models/instance-settings.zmodel (1)
1-10: Singleton InstanceSettings model looks intentional and coherentThe
InstanceSettingsshape and mappings look good, andid Int @id @default(1)correctly encodes a single-row settings table backed by@@map("instance_settings"). As long as callers treat this as a singleton (e.g., via upsert), there’s no issue.packages/orm/src/client/crud/dialects/base-dialect.ts (1)
863-902: Widenedomittype inbuildSelectAllFieldsmatches call sitesAllowing
omitto beRecord<string, boolean | undefined> | undefined | nullis consistent with the way it’s passed frombuildModelSelect(payload?.omit) and keeps the internalomit?.[field]checks safe. No behavioral change beyond acceptingnullexplicitly.tests/e2e/apps/rally/zenstack/models/licensing.zmodel (1)
1-54: Licensing schema models and mappings are well-structuredThe enums and the three licensing models are modeled cleanly: column/table mappings are consistent,
licenseKeyis unique, and theLicense–LicenseValidationrelation vialicenseIdwithonDelete: Cascadeis correctly wired.InstanceLicensemirroringLicensebut mapped to its own table also makes sense for instance-scoped licensing.tests/e2e/apps/rally/zenstack/models/poll.zmodel (1)
1-172: Poll schema models and relations look consistentEnums, field mappings, relations, and indexes align cleanly with the imported User/Space/Event models and typical Prisma/ZenStack patterns. I don’t see any correctness issues here.
tests/e2e/apps/rally/zenstack/models/billing.zmodel (1)
1-60: Billing models integrate cleanly with existing User/Space schemaSubscription and PaymentMethod are well-formed, with appropriate mappings, relations, and indexes. The schema looks correct for the intended billing use cases.
tests/e2e/apps/rally/zenstack/input.ts (1)
1-550: Generated rally input types are coherent and consistentThe exported
*Args,*WhereInput/Select/Include/Omit, and*GetPayloadaliases follow a uniform pattern across all models and line up with the shared ORM types. Given this is generated, I wouldn’t change anything here manually.packages/clients/tanstack-query/src/svelte.ts (1)
137-210: Svelte ModelQueryHooks generics correctly updated to 2‑arity argsThe updated
T extends *Args<Schema, Model>constraints match the current ORM definitions and mirror the Vue/React clients, with no runtime changes. Typing remains sound for all hooks.The
rgscript suggested in the Vue client comment will also cover this file to ensure there are no leftoverArgs<Schema, Model, true>usages.packages/clients/tanstack-query/src/vue.ts (1)
121-195: Review verified: Vue ModelQueryHooks generics correctly aligned with ORM type aliasesVerification confirms Vue is using the correct 2-parameter forms of ORM type aliases (
FindManyArgs<Schema, Model>,CreateArgs<Schema, Model>, etc.) consistently throughout the file. The ORM's grep matches showing 3-arity patterns were alias definitions in the ORM itself, not Vue code. No type incompatibilities found.tests/e2e/apps/rally/zenstack/models/user.zmodel (1)
7-129: User/auth schema wiring looks consistentEnums, mapped column names, and relations between
User,Account,Session, and impersonation (ImpersonatedSessions) are wired coherently and match the imported modules. Cascade andSetNullbehaviors on relations also look appropriate for auth/session data, so nothing blocking from this file.tests/e2e/apps/rally/zenstack/models/event.zmodel (1)
5-83: Scheduling models and relations look correct
ScheduledEvent,RescheduledEventDate, andScheduledEventInvitehave consistent FK fields, mappings, and cascade/SetNull behaviors. The hash indexes onspaceId/userIdfit a PostgreSQL setup and should be fine as long as Rally stays Postgres-only.packages/orm/src/client/contract.ts (1)
246-799: CRUD operation type signatures align with refactored ArgsThe
AllModelOperationsgenerics now consistently use the refactored*Args<Schema, Model>types fromcrud-types.ts, and theSelectSubset/Subsetusage matches those definitions. This keeps the public contract coherent with the new schema-agnostic arg shapes without changing runtime behavior.packages/orm/src/client/crud-types.ts (8)
244-379: Schema-agnostic primitive filter stack looks soundThe refactoring of
PrimitiveFilterand the concreteStringFilter/NumberFilter/DateTimeFilter/BytesFilter/BooleanFiltertypes to drop theSchemageneric while still threadingNullableandWithAggregationsthroughEnumFilterandWhereInputkeeps the filter surface expressive and matches how these types are consumed elsewhere. The recursivenotshapes and aggregation members (_count,_avg,_sum,_min,_max) remain consistent and shouldn’t regress existing query typings.
444-500: Select/include/omit helper now cleanly controls relations and_countThe updated
SelectIncludeOmitandSelectInputsignatures, with an explicitAllowRelationparameter and nullableselect/include/omit, give you finer control over when relation selection and_countare allowed. This nicely supports scenarios likecreateManyAndReturn/updateManyAndReturnwhere only scalar selection should be permitted.
674-685: Create argument types correctly reuse selection helpers
CreateArgsandCreateManyAndReturnArgsnow composeSelectIncludeOmitdirectly, withAllowCountandAllowRelationtuned for the operation (AllowRelation = falseandOmit<'include'>forCreateManyAndReturnArgs). This cleanly encodes the constraints that bulk-returning operations can’t include relations while still allowing scalarselect/omit.
810-837: Update and upsert arg types match the new selection surface
UpdateArgs,UpdateManyArgs,UpdateManyAndReturnArgs, andUpsertArgsall properly reuseUpdateInput/UpdateManyPayloadalong withSelectIncludeOmit<..., true>, and the same “no include / no relations” pattern is applied toUpdateManyAndReturnArgsas for the create counterpart. This keeps the update/upsert operations consistent with the rest of the CRUD arg model.
948-955: Delete arg types remain straightforward
DeleteArgsandDeleteManyArgsare expressed directly in terms ofWhereUniqueInputandWhereInput, withlimitonDeleteManyArgsfor safer bulk deletes. The reuse ofSelectIncludeOmit<..., true>forDeleteArgsmaintains parity with the other single-entity operations.
961-966: CountArgs composition over FindArgs is consistent
CountArgsnow wrapsFindArgs<Schema, Model, true>and explicitly omitsselect/include/distinct/omit, then adds its ownselect?: CountAggregateInput | true. This keeps filtering, pagination, and ordering behavior aligned withfindManywhile clearly separating the count projection.
986-1000: AggregateArgs matches Prisma-style aggregation patternsThe new
AggregateArgsobject shape (where,skip,take,orderBy, plus_count,_min,_max, and the conditional_avg/_sum) matches the expected aggregate API and uses the sharedOrderBy,CountAggregateInput,MinMaxInput, andSumAvgInputhelpers. This should give predictable typings for aggregate queries across all models.
1071-1088: GroupByArgs captures grouping and aggregation constraints cleanly
GroupByArgsnow explicitly requiresby(single field or non-empty array of non-relation fields), with optionalwhere,orderBy,having,take, andskip, and reuses the same aggregate inputs asAggregateArgs. The conditional inclusion of_avg/_sumbased onNumericFieldskeeps the type surface precise for models without numeric fields.tests/e2e/apps/rally/zenstack/models.ts (1)
1-64: Generated Rally model and enum typings are consistentThe
$ModelResult<$Schema, "...">aliases and enum constant/type pairs line up with the Rally zmodel schema (user, event, space, licensing, etc.), and the file is clearly marked as generated. Nothing to change here unless the generator itself is updated.
Docstrings generation was requested by @ymc9. * #406 (comment) The following files were modified: * `packages/cli/src/actions/action-utils.ts` * `packages/cli/src/actions/db.ts` * `packages/cli/src/actions/migrate.ts` * `packages/cli/src/utils/exec-utils.ts` * `packages/testtools/src/client.ts` * `tests/e2e/scripts/generate.ts`
* fix(orm): reimplement typescript type display simplification * update * fix(orm): findUnique arg typing
|
Claude finished @ymc9's task —— View job PR Review: merge dev to main (v3.0.0-beta.23)Comprehensive review completed for this release preparation PR with 68 changed files. Todo List:
Review SummaryThis PR represents a solid release preparation with significant improvements to type safety, CLI utilities, and test coverage. The changes are well-structured and maintain backward compatibility while introducing valuable enhancements. 🟢 Strengths1. TypeScript Type System Improvements
2. CLI Enhancements
3. Comprehensive Test Coverage
4. Code Quality
🟡 Areas for Improvement1. Documentation
2. Error Handling
3. Performance Monitoring
🟢 Security Assessment
🟢 Performance Considerations
🟢 Test Coverage
Recommendation: ✅ APPROVEThis is a well-executed release preparation that:
The changes are ready for production deployment to v3.0.0-beta.23. Next Steps
|
Summary by CodeRabbit
Release Notes
New Features
schema.zmodelfiles within configured paths.Bug Fixes
Tests
Chores