fix: Update DeepPartial for usage of generics with Repository class

[nelsonfleig]

Description of change

Update DeepPartial to work with a generic passed to Repository then testing on an abstract service.

This issue is related with Fixes #8681

Pull-Request Checklist

• Code is up-to-date with the master branch
• npm run format to apply prettier formatting
• npm run test passes with this change
• This pull request links relevant issues as Fixes #8681
• There are new or updated unit tests validating the change
• Documentation has been updated to reflect this change
• The new commits follow conventions explained in CONTRIBUTING.md

[pbrn46]

It seems after the create() call, a non-deeppartial is returned to be used for the save() call, The save() call doesn't like it, since apparently a generic T can't be used as a parameter expecting a generic DeepPartial in the .save() signatures (save<T extends DeepPartial<Entity>>, for example). TS won't be able to figure out which overload to use. I would assume this is the same for the .create() signatures.

Using a signature like this seems to work:

-  save<T extends DeepPartial<Entity>>
+  save<T extends Entity | DeepPartial<Entity>>

Since the above works, we can instead union the original T as part of the DeepPartial type. This seems to work even better as it has fewer changes to core code, and will be more flexible for future use cases. TS now seems to be able to decide on the right one since the non-deeppartial type is now explicitly available:

- export type DeepPartial<T> = T extends Array<infer U>
+ export type DeepPartial<T> = T | (T extends Array<infer U>
    ? DeepPartial<U>[]
    : T extends Map<infer K, infer V>
    ? Map<DeepPartial<K>, DeepPartial<V>>
    : T extends Set<infer M>
    ? Set<DeepPartial<M>>
    : T extends object
    ? { [K in keyof T]?: DeepPartial<T[K]> }
-    : T
+    : T)

I ran this new DeepPartial through all the tests and they seem to pass as well.

Aside: Also added an await to the service create call to pass the test in this PR.

[nelsonfleig]

It seems after the create() call, a non-deeppartial is returned to be used for the save() call, The save() call doesn't like it, since apparently a generic T can't be used as a parameter expecting a generic DeepPartial in the .save() signatures (save<T extends DeepPartial<Entity>>, for example). TS won't be able to figure out which overload to use. I would assume this is the same for the .create() signatures.

Using a signature like this seems to work:

-  save<T extends DeepPartial<Entity>>
+  save<T extends Entity | DeepPartial<Entity>>

Since the above works, we can instead union the original T as part of the DeepPartial type. This seems to work even better as it has fewer changes to core code, and will be more flexible for future use cases. TS now seems to be able to decide on the right one since the non-deeppartial type is now explicitly available:

- export type DeepPartial<T> = T extends Array<infer U>
+ export type DeepPartial<T> = T | (T extends Array<infer U>
    ? DeepPartial<U>[]
    : T extends Map<infer K, infer V>
    ? Map<DeepPartial<K>, DeepPartial<V>>
    : T extends Set<infer M>
    ? Set<DeepPartial<M>>
    : T extends object
    ? { [K in keyof T]?: DeepPartial<T[K]> }
-    : T
+    : T)

I ran this new DeepPartial through all the tests and they seem to pass as well.

Aside: Also added an await to the service create call to pass the test in this PR.

Great. Updated DeepPartial with @pbrn46 recommendations. Tests pass!

[H4ad]

If merged it will close this issue too #8698

[nelsonfleig]

Failing cockroachdb test. Unsure why. Any ideas?

[pleerock]

@nelsonfleig cockroachdb is super dumb. I'm going to restart the tests.

[pbrn46]

Also, beware the package-lock.json has been updated to lockfile v2 in the first commit. Not sure if that would affect the tests. :)

[nelsonfleig]

Also, beware the package-lock.json has been updated to lockfile v2 in the first commit. Not sure if that would affect the tests. :)

True that could be. Shouldn't have commited that. Will restore it now.

[nelsonfleig]

Unfortunately the same cockroachdb test still fails despite restoring the package-lock.json

1) repository > find options > locking
       should allow on a left join:
     Error: You must provide selection conditions in order to find a single row.

I also see other PRs failing in the same test.

[nelsonfleig]

Any updates on the failing cockroachdb test?

[pleerock]

test was failing due to issue on master branch. Let me merge this PR.