fix: make ".zenstack/models" reexport the entire original PrismaClient module #2070
Conversation
📝 WalkthroughWalkthroughThis pull request refactors the Changes
Assessment against linked issues
Possibly related PRs
✨ Finishing Touches
🪧 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: 0
🧹 Nitpick comments (1)
tests/regression/tests/issue-foo.test.ts (1)
3-3: Enhance test description with specific issue reference.The test description only includes "issue [...]" which lacks specificity. Consider updating it to explicitly reference the issue number (2065) to improve traceability and documentation.
-describe('issue [...]', () => { +describe('issue #2065: PrismaClient module reexport', () => {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
tests/regression/tests/issue-foo.test.ts(1 hunks)
🧰 Additional context used
🧬 Code Definitions (1)
tests/regression/tests/issue-foo.test.ts (1)
packages/testtools/src/schema.ts (1)
loadSchema(163-369)
⏰ Context from checks skipped due to timeout of 90000ms (5)
- GitHub Check: build-test (20.x)
- GitHub Check: OSSAR-Scan
- GitHub Check: Analyze (javascript-typescript)
- GitHub Check: build-test (20.x)
- GitHub Check: build-test (20.x)
🔇 Additional comments (3)
tests/regression/tests/issue-foo.test.ts (3)
4-36: Good regression test for Zod schema validation with enum types.This test effectively validates that the Zod schema generation works correctly with enum types, JSON fields, and validation rules. It aligns with the PR objective of ensuring the PrismaClient module is properly reexported.
The test structure is clear and focused:
- Defines a schema with an enum, a custom type, and a model with validation
- Loads the schema with appropriate options
- Verifies that object validation works as expected
21-24: LGTM: PostgreSQL provider with DB push disabled is appropriate for this test.Using PostgreSQL as the provider with DB push disabled is appropriate for a schema validation test that doesn't require database interaction.
18-18:✅ Verification successful
Verify that validation rule syntax is compatible with latest ZenStack version.
The validation rule syntax
@@validate(type == Bar, "FooType must be Bar")uses an unquoted enum value. While this test passes, ensure this syntax is officially supported and documented.
🌐 Web query:
Does ZenStack support unquoted enum values in validation rules?💡 Result:
ZenStack supports the use of unquoted enum values in validation rules when working with enum-typed fields. Here's a detailed breakdown:
Enum Definition Syntax
Enum values are declared without quotes in ZModel:enum Beverage { SODA COFFEE BEER COCKTAIL }These enum identifiers are then used directly in validation rules[1].
Validation with Enums
When validating enum-typed fields, you reference enum values without quotes:model Order { beverage Beverage adult Boolean @@validate(adult || beverage in [SODA, COFFEE], 'Alcohol requires adult verification') }The
inoperator accepts enum values directly[2][3].String Fields with Enum-like Validation
For databases that don't support enums (like SQLite), you can enforce enum-like behavior using string fields with validation:model Order { beverage String @regex('^(SODA|COFFEE|BEER|COCKTAIL)$') @@validate(beverage in ['SODA', 'COFFEE', 'BEER', 'COCKTAIL']) }In this case, quotes are required for string literals[2][3].
Generated Zod Schemas
When using the@core/zodplugin, enum-typed fields generate Zod schemas that enforce type-safe enum values without quotes, while string-based enum validations produce regex or literal checks with quoted values[5].The key distinction lies in whether you're using native enums (unquoted values) or simulating enums through string validation (quoted values). ZenStack's validation syntax adapts accordingly based on the field type[1][2][5].
Citations:
- 1: https://zenstack.dev/docs/reference/zmodel-language
- 2: https://zenstack.dev/docs/the-complete-guide/part1/data-validation
- 3: https://zenstack.dev/blog/form-validation
- 4: https://charpeni.com/blog/graphql-enums-are-unsafe
- 5: https://zenstack.dev/docs/reference/plugins/zod
- 6: Adding
@@ignoreto a model that references an enum fails to generate enhanced client #1835- 7: Model-level validation corrupts field date serialization/validation for RESTful handler #1067
- 8: https://zenstack.dev/docs/the-complete-guide/part1/access-policy/expr-func
- 9: "Reference not resolved" error when using an
enumfrom an imported schema in@default#1849- 10: [BUG] Enum with "DateTime" Value #1399
Validation rule syntax is officially supported.
After verifying the latest ZenStack documentation, using an unquoted enum value in the validation rule (as in@@validate(type == Bar, "FooType must be Bar")) is indeed supported when validating enum-typed fields. No further changes are needed for this test case.
fixes #2065