feat(frontend): match sdk error types casing

[hassan254-prog]

##Describe the problem and your solution

• Match sdk error types casing

---

This PR updates all frontend SDK authentication error type string literals and related documentation from camelCase (e.g., 'missingAuthToken') to snake_case (e.g., 'missing_auth_token') to match industry convention. Changes are made to type definitions, error construction logic, UI error handling, and the SDK reference documentation for consistency and future extensibility.

Key Changes:
• Replaced all camelCase AuthErrorType values with snake_case equivalents in 'packages/frontend/lib/types.ts' and corresponding usage throughout the frontend SDK.
• Updated error instantiation locations and error handling logic to use new snake_case error codes.
• Aligned UI error presentation in Connect UI to expect new error type casing ('window_closed', etc.).
• Revised reference documentation (docs-v2/reference/sdks/frontend.mdx) to match new error codes and descriptions.

Affected Areas:
• Frontend SDK type definitions and error handling ('packages/frontend/lib/types.ts', 'packages/frontend/lib/index.ts')
• Connect UI error display logic ('packages/connect-ui/src/views/Go.tsx')
• Frontend SDK documentation ('docs-v2/reference/sdks/frontend.mdx')

This summary was automatically generated by @propel-code-bot

[linear]

EXT-702 Clean up frontend SDK casing

[bodinsamuel]

unfortunately this would be a breaking changes for a lot of customers

[khaliqgant]

unfortunately this would be a breaking changes for a lot of customers

Indeed. We could do our "normal" deprecation pattern.

1. Make these additions only
2. Remove the ones we're replacing from any documentation
3. Add a deprecation notice to the ones that we will no longer support
4. Set a deprecation date

[hassan254-prog]

@khaliqgant and @bodinsamuel , I suppose there's no way to deprecate individual string literals within a union type for AuthErrorType. To take a cleaner approach, I thought it best to deprecate AuthError entirely and replace it with a new AuthErrorV2, which now uses enums for better future-proofing. If needed, we can deprecate individual auth error types within the enum moving forward.

[TBonnin]

a simpler API would be in my opinion to no pass the legacyType and internally map the AuthErrorTypeV2 to the legacy one (since the legacy one are not gonna evolve anymore). wdyt?

[bodinsamuel]

Deprecated doesn't raise any alarm in typescript so I wouldn't use that as a safety net. Not entirely sure what does AuthErrorV2 bring since it's still not retro-compatible and still breaking.

If we really want to achieve this, I only see two options:

• opt-in for new errors and have the two system running together
• announce breaking change and just go with it

I would just go for later if that's an accepted risk. So maybe your first option was fine but I'm still not sure why we bother tbh

---

Tegarding enum I would try not to use them more, since even Microsoft acknowledge they are not good. The only annoying part is @deprecated but you can use a regular object or constant playground

[hassan254-prog]

Deprecated doesn't raise any alarm in typescript so I wouldn't use that as a safety net. Not entirely sure what does AuthErrorV2 bring since it's still not retro-compatible and still breaking.

If we really want to achieve this, I only see two options:

• opt-in for new errors and have the two system running together
• announce breaking change and just go with it

I would just go for later if that's an accepted risk. So maybe your first option was fine but I'm still not sure why we bother tbh

Tegarding enum I would try not to use them more, since even Microsoft acknowledge they are not good. The only annoying part is @deprecated but you can use a regular object or constant playground

AuthErrorV2 introduces the correct casing convention (snake_case) that we’ll be using moving forward. It includes support for future deprecation scenarios. At the same time, we’re maintaining support for the original AuthError to avoid breaking changes for existing customers and to give them time to migrate to AuthErrorV2. The plan is to eventually remove AuthError, but new users will be guided to use AuthErrorV2 via the documentation. This is my first time introducing such a breaking change for users in Nango, I will need proper guidance ☺️ .

[bodinsamuel]

I understand the new class it's just that it's a breaking change, so there is no need to introduce a new layer if it's also breaking.
What will happen if we merge:

• People staying before this version = no problem
• People upgrading = they have to use AuthErrorV2 because AuthError is no longer thrown

If you want to upgrade without breaking change you need to do the opposite, by no changing type and introducing a new type

class AuthError {
 type,
 typeV2
}

But if you do that, that nobody will upgrade since no TS errors will be raised. So that's why I'm saying, maybe the only way is just to create a breaking change and be done with it.

[hassan254-prog]

I understand the new class it's just that it's a breaking change, so there is no need to introduce a new layer if it's also breaking. What will happen if we merge:

• People staying before this version = no problem
• People upgrading = they have to use AuthErrorV2 because AuthError is no longer thrown

If you want to upgrade without breaking change you need to do the opposite, by no changing type and introducing a new type

class AuthError {
 type,
 typeV2
}

But if you do that, that nobody will upgrade since no TS errors will be raised. So that's why I'm saying, maybe the only way is just to create a breaking change and be done with it.

Aaah, that makes perfect sense, thanks! I think going for it with the breaking changes is the only way. I've reverted to the initial commit of the PR.

[TBonnin]

what's the plan to release this breaking change?