fix(prisma): add useDefineForClassFields option to default ts compilation option #2930
Conversation
WalkthroughThe changes involve modifications to the Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant GenerateCodeFunction
participant Project
User->>GenerateCodeFunction: Call generateCode()
GenerateCodeFunction->>Project: Instantiate Project with compilerOptions
Project->>GenerateCodeFunction: Return Project instance
GenerateCodeFunction->>User: Return generated code
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 (
|
…tion option Closes: #2927
Romakita
force-pushed
the
fix-prisma-compilation-options
branch
from
7a1ebd6 to
29c0824
Compare
![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
🧹 Outside diff range comments (1)
packages/orm/prisma/src/generator/generateCode.ts (1)
Line range hint
13-19: Consider adding documentation for compiler optionsIt would be helpful to add a comment explaining why
useDefineForClassFieldsis set tofalseand its implications for class field behavior.Here's a suggested addition:
const baseCompilerOptions: CompilerOptions = { target: ScriptTarget.ESNext, module: ModuleKind.ESNext, emitDecoratorMetadata: true, experimentalDecorators: true, esModuleInterop: true, + // Maintains backward compatibility with traditional class fields behavior + // This ensures consistent behavior with decorators and class field initialization useDefineForClassFields: false };
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
📒 Files selected for processing (2)
packages/orm/prisma/src/generator/generateCode.ts(2 hunks)packages/orm/prisma/vitest.config.mts(1 hunks)
🔇 Additional comments (3)
packages/orm/prisma/vitest.config.mts (1)
13-16: Verify the coverage threshold reduction
The coverage thresholds for statements and lines have been reduced by 0.09%. While this is a minor reduction, it would be helpful to understand if this is related to the new useDefineForClassFields compiler option implementation.
Let's check the test coverage changes:
packages/orm/prisma/src/generator/generateCode.ts (2)
35-37: LGTM: Improved code formatting
The conditional spread operator formatting enhances readability without changing functionality.
18-19: LGTM: Added useDefineForClassFields compiler option
Setting useDefineForClassFields to false maintains backward compatibility with the traditional class fields behavior in TypeScript.
Let's verify the impact of this compiler option:
✅ Verification successful
Based on the results, I can now generate the final response since I have enough information about class field usage in the codebase.
Setting useDefineForClassFields to false is appropriate for this codebase
The codebase extensively uses class fields with initializers, particularly in service classes and containers. This compiler option ensures consistent class field behavior across the codebase, especially for:
- Private fields with
#prefix (e.g.,#listeners,#providers,#perf) - Public fields with initializers (e.g.,
recipes: Recipe[] = [...]) - Map initializations (e.g.,
types: Map<...> = new Map())
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for class field usage that might be affected
# Look for class field declarations
ast-grep --pattern 'class $_ {
$$$
$_: $_ = $_
$$$
}'
# Look for potential decorator usage on class fields
ast-grep --pattern '@$_($$$)
$_: $_'
Length of output: 50355
|
🎉 This PR is included in version 8.3.2 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
Summary by CodeRabbit