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[bot]]

EXT-702 Clean up frontend SDK casing

[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.

[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?

[hassan254-prog]

what's the plan to release this breaking change?

Announce the breaking change with the newer version of the frontend SDK once it is merged and the version is bumped.

[hassan254-prog]

@bodinsamuel , could you please help release this 🙏 .

[gitguardian[bot]]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
17919377	Triggered	Generic Password	411a913c520b16993dc5d6b726d9548ac77fc281	.github/workflows/managed-release.yaml	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}