supabase / auth-js / 17979121627

71%

push

github

fix: prettify types and improved typesafety for MFA methods (#1116)

## What kind of change does this PR introduce?

This is a preparatory PR for adding webauthn support, which will have
different params/responses across the
`client.mfa.{enroll/challenge/verify}()` methods.

At the moment, some parameters in the calls are present in the type even
when they are not valid for that factor/method type, and the response
signature that the function returns does not match what's actually being
returned.

Also, in some instances of the types returned, we can assert some values
in the return types as being one property of the valid union types in
that property, for example:

in the call to `client.mfa.listFactors()` an object returns which
contains:`

```json
all: [],
totp: [],
phone: [],
```

If the developer tries to iterate through this list, the `factor_type`
will be a union of all the possible values in `.all`, and status will be
`verified | unverified` which is correct.
but in `.phone`, we *know* that it's of type `phone` and that its status
is `verified`, thus, we can assert this in the type, the `Factor`
signature has been updated to accept 2 generics (which are optional),
which enable us to set specific shapes in different parts of the
library, some other examples:

- In `.enroll()`, we *know* for a *fact* that the `.type()` of the
factor will match the `factorType` that was passed in the function call,
- Similarly, in the `AuthMFAChallengeResponse`, we *know* for a fact
that the `.type` property will always be `totp` or `phone` based on what
parameters were passed.

I believe these type revamps greately enhance the Developer Experience &
enable the developer to not make any mistakes while accessing those
fields.

It will also enable us to add specific documentation/links that will
appear in intellisense depending on which parameters were passed to each
function.

## What is the current behavior?

Most calls to the backend result in either:

```typesc... (continued)

1080 of 1442 branches covered (74.9%)

Branch coverage included in aggregate %.

15 of 15 new or added lines in 2 files covered. (100.0%)

1456 of 1696 relevant lines covered (85.85%)

172.92 hits per line