chore(repo): monorepo transition [skip ci] #1573
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* fix(types): type result for throwOnError responses When using throwOnError(), the response type is now more strictly typed: - Data is guaranteed to be non-null - Error field is removed from response type - Response type is controlled by generic ThrowOnError boolean parameter Fixes #563 * chore: re-use generic types * fix: return this to comply with PostgresFilterBuilder * chore: fix test to check inheritance and not equality
chore: add test coverage to postgrest-js
feat(types): add json path type inference
When using MergeDeep type-fest even with simple structures we get this error For typescript > 4.5.5 this trick fix the issue by forcing TS to infer the value And reuse it instead of computing multiple time
…to refresh (#1027) When `autoRefreshToken` is off (or when a tab is in the background) but `getSession()` is called -- such as in an active Realtime channel, `getSession()` might return a JWT which will expire while the message is travelling over the internet. There is one confirmed case of this happening. This PR adjusts this using the established `EXPIRY_MARGIN_MS` constant (which only applies on initial initialization of the client). The constant's value is brought in line with the `autoRefreshToken` ticks which run every 30 seconds and refreshing is attempted 3 ticks prior to the session expiring. This means that JWTs with an expiry value **less than 90s** will always refresh the session; which is acceptable.
🤖 I have created a release *beep* *boop* --- ## [2.68.0](supabase/auth-js@v2.67.3...v2.68.0) (2025-01-21) ### Features * consider session expired with margin on getSession() without auto refresh ([#1027](supabase/auth-js#1027)) ([a51dbb0](supabase/auth-js@a51dbb0)) ### Bug Fixes * remove `internal-types.ts` ([#1014](supabase/auth-js#1014)) ([902ec1d](supabase/auth-js@902ec1d)) * update docs to add scrypt ([#1012](supabase/auth-js#1012)) ([0dc969a](supabase/auth-js@0dc969a)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
…on-error fix(types): type instantiation is excessively deep and possibly infinite
## What kind of change does this PR introduce? Bug fix ## What is the current behavior? Type checking and/or linting does not pass for some configurations, per supabase/auth-js#967 and supabase/auth-js#1017 ## What is the new behavior? We're now asserting that `parts[1]` is a string (aka isn't undefined), since we know from a previous check that the array length is 3. ## Additional context Fixes #967 and fixes #1017 Co-authored-by: Kang Ming <[email protected]>
remove client side check of jwt token
## What kind of change does this PR introduce? * `getClaims` supports verifying JWTs (both asymmetric and symmetric) and returns the entire set of claims in the JWT payload --------- Co-authored-by: Stojan Dimitrovski <[email protected]>
* fix: Change format of version sent * get version from x-client-info header * add tests --------- Co-authored-by: Guilherme Souza <[email protected]>
- Allow to use returns at the end of the call chain after a .single() - Add deprecation warning to move toward explicit overrideTypes method - Add cast checking basic logic, an array should be declared if the result is an array, an object if the result is an object
## 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:
```typescript
type ExampleCalltoT = {data: T, error: null} | {data: null, error: AuthError}
```
or
```typescript
type ExampleCalltoT = {data: T, error: null} | {data: ...keys of T set to null, error: AuthError}
```
Also, there was no distinction in calls to `.enroll()` and
`.challenge()`
## What is the new behavior?
- Consolidate response patterns into `RequestResult<T>` and
`RequestResultSafeDestructure<T>`
- Provide better type inference and IDE support with `Prettify<T>`
utility
- Add specific overloads to each function so that all the possible
parameters show up in the IDE, then narrow down as soon as you lock into
a specific parameter.
- Update AMR Methods to include everything that's supported by the
GoTrue backend.
### Key improvements
1. **Generic response utilities**:
- `RequestResult<T>` - Standard result type with data/error pattern
- `RequestResultSafeDestructure<T>` - Allows safe destructuring with
null safety
- `Prettify<T>` - Improves IDE hover experience by resolving mapped
types
2. **Enhanced type safety**:
- Stronger typing for MFA factor types using discriminated unions
- Better type narrowing for factor verification status
- Consistent error type handling across all responses
3. **Internally breaking change**:
- `_callRefreshToken` now returns `{ data: Session, error: null }`
instead of `{ session: Session, error: null }`, for consistency, this
will not affect users as it's an internal utility (tests have been
adjusted to accomodate this)
## Additional context
This refactoring improves developer experience by:
- Making response types more predictable and easier to work with
- Providing better IntelliSense/autocomplete in IDEs
- Reducing the likelihood of type-related bugs
- Making the codebase more maintainable
All existing tests pass with minimal adjustments to accommodate the
internal API change, and to prepare for the next PR here that adds
webauthn types, which require that some function calls have distinct
parameters/responses to not confuse users and guide them to use the
library correctly using the TYPES as a source of truth, so the developer
can use the api naturally just through the types.
Adds `linkIdentity()` method which allows passing OIDC credentials. The ID token will be linked to the currently signed in user. See also: - supabase/auth#2108
## What kind of change does this PR introduce? Add a `fail-on-error: false` to `coveralls` uploads. Change `coverageapp` version used from `master` to `v2`, so that it accepts this input. ## What is the current behavior? Coveralls seems to be failing, and being flaky. ## What is the new behavior? If `coveralls` upload fails, the CI will not fail.
## What kind of change does this PR introduce?
**Feature** - This PR introduces YubiKey support for Multi-Factor
Authentication (MFA) via WebAuthn, enabling users to authenticate with
hardware security keys.
## What is the current behavior?
Currently, Supabase Auth JS supports two MFA methods:
- TOTP (Time-based One-Time Password) authenticators
- SMS-based verification
## What is the new behavior?
This PR adds full WebAuthn support to the authentication library, the
defaults enable yubikey support at the moment, but it allows the user to
override some parameters client-side to use other types of passkey
methods.
The PR adds the 'webauthn' factor type, to `listFactors`, `enroll()`,
`challenge()`, and `verify()`
(De)serialization of the webauthn reponse/credential object is done
behind the scenes via dedicated objects.
it also adds a new `experimental` namespace `.mfa.webauthn` which has a
`.register()` and `.authenticate()` methods, these methods allows
**single click** yubikey 2FA addition with a single function call.
additionally, we have `webauthn.{enroll|challenge|verify}()`, which
abstract away some of the logic surrounding enrollment, interaction with
the verifier, and have defaults for factortype etc.
### Two ways to use the new api:
#### Single Step
```typescript
const { data, error } = await client.mfa.webauthn.register({
friendlyName: `Security Key ${new Date().toLocaleDateString()}`,
rpId: window.location.hostname,
rpOrigins: [window.location.origin]
}, {
authenticatorSelection: {
authenticatorAttachment: 'platform',
residentKey: 'discouraged',
userVerification: 'discouraged',
requireResidentKey: false
}
});
if (error) throw error;
console.log(data); // <- session
```
#### Multi Step Composition
```typescript
const { enroll, challenge, verify } = new WebAuthnApi(client);
return enroll({
friendlyName: params.friendlyName
})
.then(async ({ data, error }) => {
if (!data) {
throw error;
}
console.log(`enrolled factor, id: ${data.id}`, 'success');
return await challenge({
factorId: data?.id,
webauthn: {
rpId: params.rpId,
rpOrigins: params.rpOrigins
},
signal: undefined
});
})
.then(async ({ data, error }) => {
if (!data) {
throw error;
}
console.log(`challenged factor, id: ${data.factorId}`, 'success');
return await verify({
factorId: data.factorId,
challengeId: data.challengeId,
webauthn: {
rpId: params.rpId,
rpOrigins: params.rpOrigins,
type: data.webauthn.type,
credential_response: data.webauthn.credential_response
}
});
})
.then(({ data, error }) => {
if (!data) {
throw error;
}
console.log(`verified factor, id: ${data.access_token}`, 'success');
return data;
});
```
## Additional context
While this PR focuses on YubiKey support, the architecture is designed
to accommodate additional authenticator types in future releases
(platform authenticators, passkeys, etc.) without requiring significant
refactoring.
I've added `webauthn.dom.ts` and `webauthn.errors.ts` which attempt to
augment the typescript interfaces for webauthn since they are out of
date and there are some new features that its not aware of yet but are
publicly available in all major browsers.
For all such types, and due to the complexity of the API, I've added
comprehensive jsdocs for each parameter with reference to the w3a spec
for reference on their usage.
in all webauthn related methods, I've added the ability to **override**
any of the parameters we pass by default to the
`credentials.{get|create}()` method for convenience.
This PR is dependent on my previous PR for streamlining types
supabase/auth-js#1116
and this PR for `auth` supabase/auth#2163
---------
Co-authored-by: Stojan Dimitrovski <[email protected]>
🎉 Snyk checks have passed. No issues have been found so far.✅ code/snyk check is complete. No issues have been found. (View Details) |
![snyk-io[bot]](https://avatars.githubusercontent.com/in/372950?s=60&v=4){kind=small}
@supabase/auth-js
@supabase/functions-js
@supabase/postgrest-js
@supabase/realtime-js
@supabase/storage-js
@supabase/supabase-js
commit: |
mandarini
force-pushed
the
chore/monorepo
branch
3 times, most recently
from
4a4b885 to
da79d8b
Compare
mandarini
force-pushed
the
chore/monorepo
branch
2 times, most recently
from
0c52f07 to
5ace831
Compare
mandarini
force-pushed
the
chore/monorepo
branch
from
5ace831 to
326f610
Compare
mandarini
changed the title
grdsdev
approved these changes
Oct 2, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
29 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Monorepo Transition
This PR transitions the codebase to a monorepo.
It imports the full commit histories of the following repositories:
@supabase/auth-js@supabase/postgrest-js@supabase/realtime-js@supabase/storage-js@supabase/functions-jsWhy full commit history is kept
Complete commit history is preserved from each repo rather than squash:
git blame, changelog generation, etc. remain accurate).Notes
[skip ci]) to avoid triggering a canary release for thousands of imported commits.