The return value of await sdk.sessions().getCurrentUser(jwt); has a form, that doesn't match the User interface. This is an example return value:

User {
  authenticated: false,
  id: '',
  name: '',
  email: '',
  phoneNumber: ''
}

Why

For our launch we need to polish our SDK as much as possible.

The plan is to adapt as much as possible from our Corbado PHP SDK (https://www.github.com/corbado/corbado-php, branch 16-improve-sdk) but only if "no one" is doing it different in the JavaScript/TypeScript world (discuss before implementation if in doubt).

If you need to research "how others are doing something" we always look at Stripe SDKs and Auth0 SDKs.

TODOS

• Port everything to TypeScript
• Adapt PHP directory structure (have services directory etc.) 3-Days
  • Should we use interfaces for our services?
  • Implement all services PHP provides
  • Implement good error handling, probably use exceptions? In case of HTTP status codes other than 200 data should be easy accessible (see PHP ServerException)
• Add script to generate OpenAPI code (see PHP /scripts)
  • Add command to npm
• Add tools to improve sourcecode
  • eslint / eslint-ts?
  • prettier?
  • Add commands to npm
• Introduce X-Corbado-SDK header to every call (with JSON payload), see PHP
  • Key "name" with "Node.js SDK"
  • Key "sdkVersion" with current SDK version
  • Key "languageVersion" with current JavaScript version (Node.js?)
• Add integration tests (/tests/integration directory) - 1.5-Days
  • See PHP as well
  • What framework do we use and why?
  • Add command to npm
• Adapt README.md from PHP
  • Use nice badges (which are common in the JavaScript/TypeScript world)
  • Differentiate between ES5 and ES6 (see current README.md)
• Add GitHub action 1-Day
  • Adapt from PHP (structure, naming)
• Test under JavaScript and TypeScript scenarios? 1-Day
  • What versions (see matrix) do we check?
• Update references/usages of this SDK in Corbado world 2-Days
  • Update documentation (https://docs.corbado.com)
  • Update wizards
  • Update landing pages (e.g. https://www.corbado.com/passkeys/node-js)

New TODOS

• Add "private client" info to README.md
• Check if SDK runs in browser, if yes alert/throw exception (since the SDK needs an API secret it must NEVER EVERY run in an browser/public environment)

The Node.js SDK (Express) is commonly referred to as a private client, specifically designed for usage within closed backend applications. This particular SDK should exclusively be utilized in such environments, as it is crucial to ensure that the API secret remains strictly confidential and is never shared.

Acceptance criteria

• Full service coverage as in PHP
• Everything works for JavaScript and TypeScript developers

• Best Practices allgemein für eine Node.js / Express.js SDK
• Wie können wir testen und Code Coverage (allgemein diese ganzen Badges, die man kennt von anderen) hinzufügen
• Wie müssen wir die Readme verbessern (hier auch schauen, was möglich ist)
• anschließend dann bitte einen neuen Branch / PR erstellen, wo die BDPs alle eingearbeitet sind
• Mittlerweile haben wir Corbado bei npm auf eine Organisation (anstatt normalen Account) umgestellt. D.h. es könnte sein, dass man ein "@" vor "@corbado/ benötigt, damit es funktioniert. Bin mir hier allerdings nicht zu 100% sicher, daher bitte überprüfen.

Why

We have a Firebase extension that spins up a number of Firebase functions that run NodeJS. In them so far we directly make use of generated clients for frontendAPI and backendAPI. As we now have the new node-sdk we should use it inside this firebase extension.
To make this possible we need to add the following calls:

• passKeyRegisterStart
• passKeyRegisterFinish
• webAuthnRegisterStart
• webAuthnRegisterFinish
• passKeyMediationStart
• passKeyLoginStart
• passKeyLoginFinish
• emailCodeLoginStart
• emailCodeConfirm
• userDelete
• userGet
• webAuthnCredentialList
• webAuthnCredentialDelete
• userUpdate

Firebase extension code: corbado_auth_firebase (the important file is corbado_service.ts)

Acceptance criteria

•  all the generated code inside the firebase extension can be replaced by the node-sdk

Implementation idea

• add the required methods
• write integration tests (I would skip the ones for webAuthnRegisterFinish, passKeyRegisterFinish and passKeyLoginFinish because testing them is hard as you need to mock the authenticator)
• replace the generated code in the Firebase extension with the node-sdk

The order in which validation error messages come from the backend is random. So all tests with at least two validation error messages are flaky (see tests/integration/services/emailLink.test.ts for example).