fix(client): enhance type safety of the AtLeast utility type

[de-novo]

This pull request proposes improvements to the AtLeast utility type, as discussed in issue #24055 . The changes aim to address the issues highlighted in issue #20619 , specifically focusing on enhancing type inference accuracy and ensuring greater compatibility with stricter type checks. This PR introduces a refined type definition to mitigate problems related to type intersections and to bolster type safety within the Prisma codebase.

[CLAassistant]

All committers have signed the CLA.

[codspeed-hq]

CodSpeed Performance Report

Merging #24056 will not alter performance

_{Comparing de-novo:fix/client/AtLeast (1e31c2f) with main (70f363e)}

Summary

✅ 3 untouched benchmarks

[SevInf]

Hi @de-novo!
Could you please add a test for you change, which would demonstrate AtLeast not working correctly before your changes. Either disallowing something that should be allowed or allowing something that should not be. Thank you!

[de-novo]

Hello @SevInf,

Thank you for your feedback.

The current implementation of the AtLeast type generally functions well, yet the type error reported in issue #20619:

'Property ‘id’ is optional in type ‘SupplierWhereUniqueInput’ but required in type ‘{ id: string | number; code: string | number; }’,

has indeed led to some confusion during the development phase. To address this, I have opened issue #24055, proposing a change in the type definition from { id: string | number; code: string | number; } to { id: number; code: string; }, which should greatly assist in development.

While type inference in both runtime and development environments is currently functioning correctly, the changes I've made were aimed at improving the type definitions. Given these improvements are more about refinement than fixing overt issues, I am unsure how to add tests that could effectively demonstrate the previous shortcomings of the AtLeast type. Could you provide specific scenarios or examples of the type of issues you would like these tests to address?

Thank you for your assistance.

[de-novo]

Additionally, the type inference improvements suggested in issue #24055 could also benefit libraries like Typia, which utilize TypeScript types for validation. Currently, such libraries are unable to properly recognize the proposed types, rendering them unusable. However, it is expected that these improvements will resolve this issue.

[de-novo]

As mentioned earlier, since it's unclear how to approach adding tests that effectively demonstrate the previous shortcomings of the AtLeast type, I will provide four examples to illustrate this point.

suggested - prisma_fork
current - prisma

schema.prisma

Ex 1

// suggested 
Type 'string' is not assignable to type 'UserCompanyIdEmployeeNumberCompoundUniqueInput'.

// current 
Type 'string' is not assignable to type 'UserCompanyIdEmployeeNumberCompoundUniqueInput | (string & UserCompanyIdEmployeeNumberCompoundUniqueInput) | undefined'.

Ex 2

// suggested 
Type '{}' is missing the following properties from type 'UserCompanyIdEmployeeNumberCompoundUniqueInput': companyId, employeeNumber

// current 
Type '{}' is not assignable to type 'UserCompanyIdEmployeeNumberCompoundUniqueInput | (string & UserCompanyIdEmployeeNumberCompoundUniqueInput) | undefined'.

Ex 3

// suggested 
Property 'employeeNumber' is missing in type '{ companyId: string; }' but required in type 'UserCompanyIdEmployeeNumberCompoundUniqueInput'.

// current 
Type '{ companyId: string; }' is not assignable to type 'UserCompanyIdEmployeeNumberCompoundUniqueInput | (string & UserCompanyIdEmployeeNumberCompoundUniqueInput) | undefined'.
  Type '{ companyId: string; }' is not assignable to type 'string & UserCompanyIdEmployeeNumberCompoundUniqueInput'.
    Type '{ companyId: string; }' is not assignable to type 'string'.

Ex 4

// suggested 
Type '{}' is not assignable to type 'string'.

// current 
Type '{}' is not assignable to type 'string | (UserCompanyIdEmployeeNumberCompoundUniqueInput & string) | undefined'.

By aligning the type definitions more closely with expected data formats, we can prevent these common mistakes and make the codebase more intuitive for developers. This should ultimately facilitate a smoother development process and reduce potential runtime errors.