Closed bklebe closed 10 months ago
@beeuhtricks I think the reason the return type is CognitoUser | any
is partly due to the fact that when using Identity Pool Federation, user
could essentially be anything that a provider returns as a user, which won't be the same as CognitoUser
.
Reference: https://docs.amplify.aws/lib/auth/advanced/q/platform/js#identity-pool-federation
Note that this isn't from a Cognito User Pool so the user you get after calling this method is not a Cognito User.
@beeuhtricks I think the reason the return type is
CognitoUser | any
is partly due to the fact that when using Identity Pool Federation,user
could essentially be anything that a provider returns as a user, which won't be the same asCognitoUser
.
This makes sense, however there are ways to express this without totally obliterating the other type in the union, for example CognitoUser | { payload: any }
, and then we could write a type guard for CognitoUser that would allow us to branch safely on the result, yes?
@bklebe Thanks for this feedback to us, I have marked this as a feature request as we have work slated later this year to improve this.
We have published an RFC on our plan for improving TypeScript support in Amplify JS & would love to get your feedback & suggestions!
The developer preview for v6 of Amplify has officially been released with improved support for TypeScript and much more! Please check out our announcement and updated documentation to see what has changed.
This issue should be resolved within the dev preview and upcoming General Availability for Amplify v6, but let us know with a comment if there are further issues.
With the release of the latest major version of Amplify (aws-amplify@>6), this issue should now be resolved! Please refer to our release announcement, migration guide, and documentation for more information.
I want to start by saying that I write this issue without a solid understanding of the history of the project and its philosophy of TypeScript usage, and with as much an intention of learning what guarantees I should expect from this library so I can work with it more effectively as it is, as suggesting that they be made stronger.
Describe the bug
Auth.currentAuthenticatedUser()
,Auth.currentUserPoolUser()
and many others returnPromise<CognitoUser | any>
or another type that is a union with a specific type andany
. This means that these functions in practice returnPromise<any>
and notPromise<CognitoUser>
. Am I to expect that I can't assume anything about their return value, or should I be using a type assertionas CognitoUser
? Leaving aside thatCognitoUser
does not appear to fully describe what is returned by these functions, as identified by #4927, this usage of union types means using these functions is not type safe.To Reproduce Call any function (i.e. "
foo()
") on the result ofAuth.currentAuthenticatedUser()
.Expected behavior These functions should return
T
instead ofT | any
; accessing properties that do not exist on their return types should fail to typecheck.Code Snippet