Skip to content

Conversation

@ymc9
Copy link
Member

@ymc9 ymc9 commented Jul 31, 2025

Summary by CodeRabbit

  • New Features

    • No new features introduced.
  • Refactor

    • Updated database client initialization to require explicit dialect instances instead of configuration objects. This affects all usage, documentation, and test examples for SQLite and Postgres.
    • Simplified client options and removed internal dialect selection logic.
  • Documentation

    • Updated code examples in documentation and READMEs to reflect the new dialect initialization approach.
  • Chores

    • Incremented package versions to 3.0.0-alpha.16.
    • Updated dependencies, adding "kysely" to relevant sample projects.

ymc9 and others added 2 commits July 31, 2025 15:18
Copilot AI review requested due to automatic review settings July 31, 2025 07:20
@coderabbitai
Copy link

coderabbitai bot commented Jul 31, 2025

Walkthrough

This change transitions all code, documentation, and templates from configuring the ZenStack client with a dialectConfig object to using an explicit dialect property, which is now a Kysely dialect instance (e.g., SqliteDialect, PostgresDialect). All related imports, type definitions, test utilities, and example usages have been updated accordingly. Several package versions are incremented.

Changes

Cohort / File(s) Change Summary
Core Client Implementation & Types
packages/runtime/src/client/client-impl.ts, packages/runtime/src/client/options.ts
Removed internal dialect construction logic and conditional types; client now requires a direct Kysely dialect instance via dialect property.
Test Utilities & Test Suites
packages/runtime/test/utils.ts, packages/runtime/test/client-api/computed-fields.test.ts, packages/runtime/test/client-api/default-values.test.ts, packages/runtime/test/client-api/name-mapping.test.ts, packages/runtime/test/plugin/kysely-on-query.test.ts, packages/runtime/test/plugin/mutation-hooks.test.ts, packages/runtime/test/plugin/query-lifecycle.test.ts, packages/runtime/test/query-builder/query-builder.test.ts, packages/runtime/test/schemas/delegate/typecheck.ts, packages/runtime/test/schemas/typing/typecheck.ts
Updated all client initializations to use dialect: new SqliteDialect(...) or dialect: new PostgresDialect(...) instead of dialectConfig. Adjusted imports and types as needed.
Documentation & Templates
README.md, samples/blog/README.md, samples/blog/main.ts, packages/cli/src/actions/generate.ts, packages/cli/src/actions/templates.ts
Updated all code examples and templates to use the new dialect property and explicit dialect instantiation.
Package Version Bumps
package.json, packages/cli/package.json, packages/common-helpers/package.json, packages/create-zenstack/package.json, packages/eslint-config/package.json, packages/ide/vscode/package.json, packages/language/package.json, packages/runtime/package.json, packages/sdk/package.json, packages/tanstack-query/package.json, packages/testtools/package.json, packages/typescript-config/package.json, packages/zod/package.json, samples/blog/package.json, tests/e2e/package.json
Incremented version numbers from 3.0.0-alpha.15 to 3.0.0-alpha.16 in all relevant packages. In samples/blog/package.json, also added kysely as a dependency and retained better-sqlite3.
Dependency Adjustments
packages/runtime/package.json, samples/blog/package.json
Moved kysely from dependencies to peerDependencies in runtime; added kysely to blog sample dependencies.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~15–25 minutes

Possibly related PRs

  • zenstackhq/zenstack-v3#29: Introduced the dialectConfig option in example code and templates, which this PR now replaces with the explicit dialect instance approach.

Poem

🐇✨
A dialect here, a dialect there,
Now explicit, clear, and fair!
No more configs tucked away—
Kysely’s classes lead the way.
Version bumps and docs align,
ZenStack’s client feels just fine.
Hooray for code that’s neat and bright!
🥕

Note

⚡️ Unit Test Generation is now available in beta!

Learn more here, or try it out under "Finishing Touches" below.

✨ Finishing Touches
  • 📝 Generate Docstrings
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch dev

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.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai generate unit tests to generate unit tests for this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@claude
Copy link

claude bot commented Jul 31, 2025

Claude finished @ymc9's task —— View job


PR Review: Merge dev to main

Review Tasks

  • Analyze version bump changes across packages
  • Review core runtime changes in client-impl.ts and options.ts
  • Examine test file modifications
  • Check for potential bugs or issues
  • Assess performance and security implications
  • Provide comprehensive feedback

✅ Code Review Summary

This PR merges development changes that primarily focus on simplifying the Kysely dialect configuration and bumping the version to 3.0.0-alpha.16. The changes represent a significant improvement in the API design.

🔍 Key Changes Analysis

1. Runtime API Simplification

Location: packages/runtime/src/client/

What Changed:

  • Before: Complex dialectConfig object with provider-specific configurations
  • After: Direct dialect: Dialect parameter - users pass a pre-configured Kysely dialect

Code Quality: ✅ Excellent

  • Reduces cognitive load and configuration complexity
  • Follows dependency injection principles
  • More consistent with Kysely's native API
  • Eliminates the need for internal dialect factory methods
// Before (removed complexity)
dialectConfig: DialectConfig<Schema['provider']>
private getKyselyDialect() { /* complex provider matching */ }

// After (cleaner)
dialect: Dialect

2. Test Infrastructure Updates

Location: packages/runtime/test/

What Changed:

  • Updated all test utilities to use direct dialect instantiation
  • Cleaner test setup with new SqliteDialect() and new PostgresDialect()

Code Quality: ✅ Good

  • Tests are more readable and easier to understand
  • Consistent with the new API design
  • No functionality regression observed

3. Version Consistency

Location: All package.json files

What Changed:

  • Bumped all packages to 3.0.0-alpha.16
  • Maintained consistent versioning across the monorepo

🚀 Performance Implications

✅ Positive Impact:

  • Eliminates runtime dialect configuration overhead
  • Removes unnecessary abstraction layers (getKyselyDialect, provider matching)
  • Direct dialect usage should have minimal performance improvement

🔒 Security Assessment

✅ No Security Concerns:

  • No sensitive data handling changes
  • No authentication/authorization modifications
  • Changes are purely architectural improvements
  • Database connection security remains managed by Kysely dialects

🐛 Potential Issues & Recommendations

Minor Issues Found:

  1. Breaking Change Documentation ⚠️

    • This is a breaking API change for existing users
    • Migration guide should be clearly documented
    • Consider adding migration examples in README
  2. Template UpdatesAlready Handled

    • CLI templates (packages/cli/src/actions/templates.ts) were properly updated
    • Sample code shows correct new usage pattern

Suggestions:

  1. Consider Adding Validation:

    // In ClientOptions, consider:
    dialect: Dialect; // Maybe add runtime validation that dialect is properly configured
  2. Documentation:

    • Update migration guide for users moving from dialectConfig to dialect
    • Add examples for common database setups

🧪 Test Coverage Assessment

✅ Comprehensive:

  • All core functionality tests updated
  • Database client creation patterns tested
  • Both SQLite and PostgreSQL dialects covered
  • No test gaps identified

📊 Overall Assessment

Aspect Rating Notes
Code Quality ⭐⭐⭐⭐⭐ Significant API improvement, cleaner design
Performance ⭐⭐⭐⭐⭐ Minor improvements, no regressions
Security ⭐⭐⭐⭐⭐ No security concerns
Test Coverage ⭐⭐⭐⭐⭐ Comprehensive test updates
Breaking Changes ⚠️ API breaking change, needs documentation

✅ Recommendation: APPROVE

This PR represents a high-quality architectural improvement that:

  • Simplifies the client configuration API
  • Removes unnecessary abstraction layers
  • Maintains full backward compatibility at the functionality level
  • Has comprehensive test coverage
  • Follows good software engineering practices

The breaking change is justified as it significantly improves the developer experience and aligns better with Kysely's design principles.


@ymc9 ymc9 changed the title merge dev to main merge dev to main (v3.0.0-alpha.16) Jul 31, 2025
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR merges development branch changes to main, primarily involving a version bump from 3.0.0-alpha.15 to 3.0.0-alpha.16 and a significant API change to replace dialectConfig with dialect for database configuration in the ZenStack runtime.

  • Version bump across all packages to 3.0.0-alpha.16
  • Migration from dialectConfig to dialect parameter for database configuration
  • Updated imports and usage patterns to use Kysely dialect classes directly

Reviewed Changes

Copilot reviewed 32 out of 33 changed files in this pull request and generated 1 comment.

Show a summary per file
File Description
package.json Root package version bump
packages/*/package.json Version bumps across all packages
packages/runtime/src/client/options.ts API change: replaced dialectConfig with dialect parameter
packages/runtime/src/client/client-impl.ts Removed dialect creation logic, now uses provided dialect directly
packages/runtime/package.json Moved kysely from dependencies to peerDependencies
samples/blog/* Updated to use new dialect API with SqliteDialect
test files Updated test setup to use new dialect configuration
documentation Updated examples to reflect new API usage
Files not reviewed (1)
  • pnpm-lock.yaml: Language not supported

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (2)
packages/testtools/package.json (1)

3-3: Keep changelog or release notes aligned

Since @zenstackhq/testtools now targets 3.0.0-alpha.16, ensure the package’s changelog (if any) includes an entry for this release so consumers understand the change—even if it’s only dependency alignment.

packages/cli/src/actions/generate.ts (1)

52-55: Documentation updated to reflect new dialect API.

The change from dialectConfig to dialect correctly reflects the new client initialization pattern. The example aligns with the broader refactor moving to explicit Kysely dialect instances.

Consider providing a more concrete example to better guide users:

const client = new ZenStackClient(schema, {
-    dialect: { ... }
+    dialect: new SqliteDialect({ database: db })
});

This would give users a clearer understanding of the expected format.

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 99eb798 and b14512e.

⛔ Files ignored due to path filters (1)
  • pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml
📒 Files selected for processing (32)
  • README.md (2 hunks)
  • package.json (1 hunks)
  • packages/cli/package.json (1 hunks)
  • packages/cli/src/actions/generate.ts (1 hunks)
  • packages/cli/src/actions/templates.ts (1 hunks)
  • packages/common-helpers/package.json (1 hunks)
  • packages/create-zenstack/package.json (1 hunks)
  • packages/eslint-config/package.json (1 hunks)
  • packages/ide/vscode/package.json (1 hunks)
  • packages/language/package.json (1 hunks)
  • packages/runtime/package.json (2 hunks)
  • packages/runtime/src/client/client-impl.ts (2 hunks)
  • packages/runtime/src/client/options.ts (2 hunks)
  • packages/runtime/test/client-api/computed-fields.test.ts (2 hunks)
  • packages/runtime/test/client-api/default-values.test.ts (2 hunks)
  • packages/runtime/test/client-api/name-mapping.test.ts (3 hunks)
  • packages/runtime/test/plugin/kysely-on-query.test.ts (2 hunks)
  • packages/runtime/test/plugin/mutation-hooks.test.ts (2 hunks)
  • packages/runtime/test/plugin/query-lifecycle.test.ts (2 hunks)
  • packages/runtime/test/query-builder/query-builder.test.ts (2 hunks)
  • packages/runtime/test/schemas/delegate/typecheck.ts (1 hunks)
  • packages/runtime/test/schemas/typing/typecheck.ts (1 hunks)
  • packages/runtime/test/utils.ts (4 hunks)
  • packages/sdk/package.json (1 hunks)
  • packages/tanstack-query/package.json (1 hunks)
  • packages/testtools/package.json (1 hunks)
  • packages/typescript-config/package.json (1 hunks)
  • packages/zod/package.json (1 hunks)
  • samples/blog/README.md (1 hunks)
  • samples/blog/main.ts (1 hunks)
  • samples/blog/package.json (2 hunks)
  • tests/e2e/package.json (1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (4)
packages/runtime/test/schemas/typing/typecheck.ts (2)
packages/runtime/src/client/client-impl.ts (1)
  • ZenStackClient (40-46)
packages/runtime/test/schemas/delegate/schema.ts (1)
  • schema (9-464)
packages/runtime/test/schemas/delegate/typecheck.ts (2)
packages/runtime/src/client/client-impl.ts (1)
  • ZenStackClient (40-46)
packages/runtime/test/schemas/delegate/schema.ts (1)
  • schema (9-464)
samples/blog/main.ts (1)
samples/blog/zenstack/schema.ts (1)
  • schema (9-228)
packages/runtime/test/utils.ts (2)
packages/runtime/src/client/options.ts (1)
  • ClientOptions (24-64)
packages/sdk/src/schema/schema.ts (1)
  • SchemaDef (10-18)
⏰ 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). (3)
  • GitHub Check: claude-review
  • GitHub Check: build-test (20.x)
  • GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (47)
tests/e2e/package.json (1)

3-3: Confirm lock-file regeneration after version bump

The package’s version has been raised to 3.0.0-alpha.16. Make sure you committed the updated pnpm-lock.yaml (or equivalent) so CI installs the expected set of dependencies.

packages/language/package.json (1)

4-4: Version bump looks good – double-check peer/workspace ranges

Nothing else changed in this manifest. Verify that downstream packages referencing @zenstackhq/language via workspace:* don’t pin an explicit 3.0.0-alpha.15, otherwise the monorepo install may become inconsistent.

package.json (1)

3-3: Root version updated – ensure release tooling picks this up

The root package now reports 3.0.0-alpha.16. Confirm that any release scripts (e.g., turbo, CI workflows) rely on this value or the individual package versions as intended, so publishing tags remain in sync.

packages/typescript-config/package.json (1)

3-3: LGTM – no additional action required

The version increment is consistent with the rest of the workspace.

packages/cli/package.json (1)

6-6: Version bump aligns with the workspace release – LGTM
The update keeps the CLI package in sync with the coordinated alpha.16 release across the monorepo.

packages/sdk/package.json (1)

3-3: Version bump confirmed – no further action needed
@zenstackhq/sdk now matches the new prerelease tag.

packages/eslint-config/package.json (1)

3-3: Consistent version update – looks good
Configuration package reflects the collective alpha.16 bump.

packages/zod/package.json (1)

3-3: Package version increment verified
The @zenstackhq/zod package is correctly updated to 3.0.0-alpha.16.

packages/common-helpers/package.json (1)

3-3: Version bump matches the rest of the release
@zenstackhq/common-helpers now points to alpha.16; no other changes spotted.

packages/tanstack-query/package.json (1)

3-3: LGTM! Version bump is consistent with coordinated release.

The version increment from 3.0.0-alpha.15 to 3.0.0-alpha.16 aligns with the broader ecosystem changes for the dialect configuration refactor.

packages/create-zenstack/package.json (1)

3-3: LGTM! Version bump maintains consistency across packages.

The version increment to 3.0.0-alpha.16 is appropriate for maintaining version alignment across the ZenStack ecosystem during this dialect configuration refactor.

packages/ide/vscode/package.json (1)

4-4: LGTM! VSCode extension version stays aligned with runtime changes.

The version increment to 3.0.0-alpha.16 ensures the VSCode extension version remains consistent with the underlying ZenStack runtime changes.

samples/blog/package.json (2)

3-3: Version bump aligns with coordinated release.

The version increment to 3.0.0-alpha.16 maintains consistency across the sample projects and core packages.


17-18: Kysely dependency added for new dialect pattern.

The addition of kysely dependency is necessary for the transition from dialectConfig objects to explicit Kysely dialect instances (e.g., SqliteDialect). This change supports the broader API refactor described in the PR.

packages/runtime/package.json (2)

3-3: LGTM - Version bump aligns with breaking API change.

The version increment to 3.0.0-alpha.16 is appropriate for the breaking change from dialectConfig to dialect property.


79-79: LGTM - Moving kysely to peerDependencies is the right architectural decision.

Moving kysely from dependencies to peerDependencies makes sense since users now provide their own dialect instances, avoiding potential version conflicts and reducing bundle size.

packages/runtime/test/plugin/kysely-on-query.test.ts (2)

2-2: LGTM - Correct import addition for SqliteDialect.

The import statement properly adds SqliteDialect from the kysely package to support the new dialect configuration pattern.


12-12: LGTM - Proper migration to explicit dialect instance.

The client initialization correctly migrates from dialectConfig object to the new dialect property using an explicit SqliteDialect instance.

packages/runtime/test/client-api/computed-fields.test.ts (1)

58-58: LGTM - Appropriate use of mock dialect for type checking tests.

The migration from dialectConfig to dialect: {} as any is appropriate for these type-focused tests where actual database functionality isn't required, only type validation.

Also applies to: 125-125

packages/runtime/test/query-builder/query-builder.test.ts (2)

3-3: LGTM - Correct import addition for SqliteDialect.

The import statement properly adds SqliteDialect from the kysely package to support the new dialect configuration pattern.


13-13: LGTM - Proper migration to explicit dialect instance.

The client initialization correctly migrates from dialectConfig object to the new dialect property using an explicit SqliteDialect instance.

packages/runtime/test/plugin/query-lifecycle.test.ts (2)

2-2: LGTM - Correct import addition for SqliteDialect.

The import statement properly adds SqliteDialect from the kysely package to support the new dialect configuration pattern.


12-12: LGTM - Proper migration to explicit dialect instance.

The client initialization correctly migrates from dialectConfig object to the new dialect property using an explicit SqliteDialect instance.

packages/runtime/test/plugin/mutation-hooks.test.ts (2)

2-2: LGTM! Import update aligns with dialect refactor.

The addition of SqliteDialect import from kysely is consistent with the broader refactor to use explicit dialect instances.


12-12: LGTM! Client configuration updated correctly.

The change from dialectConfig to dialect property with explicit SqliteDialect instantiation is consistent with the broader API refactor and maintains the same functionality.

packages/runtime/test/schemas/typing/typecheck.ts (2)

2-2: LGTM! Import addition aligns with dialect refactor.

The addition of SqliteDialect import from kysely is consistent with the broader API changes.


7-8: LGTM! Client initialization updated correctly.

The change from dialectConfig to dialect property with explicit SqliteDialect instantiation aligns with the broader refactor while maintaining the same database functionality.

packages/runtime/test/client-api/default-values.test.ts (2)

3-3: LGTM! Import addition supports dialect refactor.

The addition of SqliteDialect import from kysely is consistent with the migration to explicit dialect instances.


72-72: LGTM! Client configuration migrated correctly.

The change from dialectConfig to dialect property with explicit SqliteDialect instantiation maintains test functionality while aligning with the new API pattern.

packages/runtime/test/schemas/delegate/typecheck.ts (2)

2-2: LGTM! Import addition supports API migration.

The addition of SqliteDialect import from kysely is consistent with the broader dialect refactor.


7-7: LGTM! Client initialization updated appropriately.

The change from dialectConfig to dialect property with explicit SqliteDialect instantiation aligns with the API refactor while maintaining the same database functionality.

packages/runtime/test/client-api/name-mapping.test.ts (3)

2-2: LGTM! Import addition supports dialect refactor.

The addition of SqliteDialect import from kysely is consistent with the migration to explicit dialect instances.


63-63: LGTM! First test client configuration updated correctly.

The change from dialectConfig to dialect property with explicit SqliteDialect instantiation maintains test functionality while aligning with the API refactor.


95-95: LGTM! Second test client configuration updated correctly.

The change from dialectConfig to dialect property with explicit SqliteDialect instantiation is consistent with the broader refactor and maintains test functionality.

samples/blog/main.ts (1)

3-3: LGTM! Dialect configuration updated correctly.

The import of SqliteDialect and the transition from dialectConfig to dialect property with explicit dialect instantiation follows the new API pattern correctly.

Also applies to: 8-8

samples/blog/README.md (1)

27-27: Documentation correctly updated for new dialect API.

The example code properly demonstrates the new pattern of importing SqliteDialect and using it as an explicit dialect instance rather than a configuration object.

Also applies to: 30-30

packages/cli/src/actions/templates.ts (1)

31-32: CLI template correctly updated for new dialect configuration.

The template now properly imports SqliteDialect and uses explicit dialect instantiation. The multi-line formatting for the dialect configuration also improves readability.

Also applies to: 36-38

README.md (2)

148-148: SQLite example correctly updated for new dialect API.

The SQLite example properly demonstrates importing SqliteDialect and using it as an explicit dialect instance.

Also applies to: 151-151


160-160: PostgreSQL example correctly updated for new dialect API.

The PostgreSQL example properly demonstrates importing PostgresDialect and using it with the connection pool configuration.

Also applies to: 165-167

packages/runtime/src/client/options.ts (1)

1-3: Core API successfully simplified to use explicit dialect instances.

The change from dialectConfig to dialect: Dialect removes internal dialect construction complexity and makes the API more explicit. This is a breaking change that requires users to instantiate Kysely dialect classes directly, but it provides better type safety and clarity.

Also applies to: 26-28

packages/runtime/test/utils.ts (5)

6-6: LGTM! Proper import of Kysely dialect classes.

The import of PostgresDialect and SqliteDialect from kysely is correctly added to support the new explicit dialect configuration pattern.


24-24: LGTM! Correct migration from dialectConfig to dialect instance.

The change from a configuration object to an explicit SqliteDialect instance with an in-memory SQLite database is appropriate for test utilities.


50-55: LGTM! Proper PostgreSQL dialect configuration.

The PostgreSQL dialect is correctly instantiated with a connection pool using the test configuration. The multi-line formatting enhances readability.


61-61: LGTM! Type definition correctly updated.

The CreateTestClientOptions type has been properly updated to omit dialect instead of dialectConfig, maintaining consistency with the new client options structure.


170-179: LGTM! Consistent dialect instantiation in createTestClient.

Both PostgreSQL and SQLite dialect instances are correctly created with appropriate configurations. The provider-specific logic ensures the right dialect is used for each database type.

packages/runtime/src/client/client-impl.ts (2)

2-2: LGTM! Import optimization for QueryExecutor type.

The import has been optimized to only include the QueryExecutor type, which aligns with the simplified client implementation that no longer handles dialect construction internally.


87-99: LGTM! Simplified client construction with external dialect instance.

The client implementation has been significantly simplified by directly using the provided dialect instance from options instead of constructing dialects internally. This change:

  • Removes complex dialect-specific construction logic
  • Makes the client more focused on its core responsibilities
  • Delegates dialect management to the caller
  • Maintains proper initialization of driver, compiler, and adapter components

The approach is cleaner and more maintainable.

@ymc9 ymc9 added this pull request to the merge queue Jul 31, 2025
Merged via the queue into main with commit 94a0c6f Jul 31, 2025
8 checks passed
@coderabbitai coderabbitai bot mentioned this pull request Aug 31, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants