Can't import error TypeScript types for AuthErrorCode

[jmagaram]

[REQUIRED] Describe your environment

• Operating System version: irrelevant Windows 10 latest
• Browser version: irrelevant latest Edge/Chrome
• Firebase SDK version: 8.2.9
• Firebase Product: AUTH

[REQUIRED] Describe the problem

I'm trying to code some auth stuff in a TypeScript Angular project, like this.auth.signOut(); and this.auth.signInAnonymously();. I'm trying to catch the errors but there seems to be no way to strongly type them using TypeScript. So I need to do code like this but can't use TypeScript intellisense to browse the available errors and get no warning if the error code string I use does not exist.

async signInAnonymously() {
  try {
    const credential = await this.auth.signInAnonymously();
  } catch (e) {
    if (e.code === 'auth/network-request-failed') {
      // do stuff
    }

The error codes are documented in...

https://firebase.google.com/docs/reference/node/firebase.auth.Error

I can see that every error is defined in this file in an enum AuthErrorCode
https://github.com/firebase/firebase-js-sdk/blob/20a88da5d935fdb8c1ff38e358c84e1939145abb/packages-exp/auth-exp/src/core/errors.ts

..But this is not publicly/easily accessible in my code. The package these are in says "This package is not intended for direct usage".

PLEASE make all the error codes accessible through a package I can import. Ideally I could get at the Enum.

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[hsubox76]

The file you're looking at is part of the experimental modular auth package that's currently in alpha, which is still undergoing some changes.

@samhorlbeck @Feiyang1 We currently aren't exporting this enum publicly out of auth-exp I think because it's a large enum that we've made a const enum to save bundle size. Is there a way to expose it without compromising the size savings? Should we expose it?

Also is it a good idea to add the definition to packages/firebase/index.d.ts for the current (non-exp) typings?

[sam-gc]

I think it would be tricky to expose the enum from an API perspective (we'd have to stick with const enum, which means it would only work in typescript and would cause weird compatibility issues when comparing TS/JS code, plus it's non-exhaustive).

One thing we could consider doing is exposing these error codes as individual consts, for example

export const AUTH_ERROR_NETWORK_REQUEST_FAILED = 'auth/network-request-failed';

This would allow tree shaking and compatibility with JS/TS both. Still not the ideal dev experience, however

[Feiyang1]

For the modular SDK, we can export an object map which is tree shakable, but we should continue to use const enum internally.
For the existing SDK, we can add an object map to the auth namespace and update packages/firebase/index.d.ts correspondingly to expose it to developers.

[sam-gc]

I didn't think object maps were tree shakable

[jmagaram]

I'm not very technical/experience with Typescript and firebase. But if I was writing error codes myself for my own Typescript code I could do something like...

type ErrorCode = 'NETWORK_REQUEST_FAILED' | 'PASSWORD_INVALID'

This gets completely erased when compiling to javascript. I'd then get intellisense to see the list of possible error codes and would get a warning if I did it wrong. Won't help javascript developers though.

[hsubox76]

I think for the original example you gave you'd ideally want an object map or enum so you could do (e.code === 'AuthError.NETWORK_REQUEST_FAILED') and not just rely on intellisense in the moment, maybe? Just guessing what users would want in general.

As for object maps not being tree shakeable I think maybe @Feiyang1 meant that the developer could just not import the map at all if they are not using the error codes, in which case, the entire map would be tree shaken out?

[jmagaram]

Yes you are right. I'd prefer e.code === AuthError.NETWORK_REQUEST_FAILED

[hsubox76]

Made a PR to do this for the current auth package: #4579

The change for the modularized (exp) version would be totally different and can be done in another PR if we decide on an approach.

[Feiyang1]

Yes, I meant it can be tree shaken out if developer didn't import it.

@samhorlbeck , See the rollup repl.

[sam-gc]

I guess my concern is that folks import the whole map without realizing what a big addition it is (only to use one or two strings out of it). There are use cases for checking the error code in production, so it's not just something you'd do while debugging either.

[hsubox76]

We've decided to provide this as an object map in the upcoming modularized version of Firebase, which is in alpha now and should be released soon. In light of that, we won't provide it in the current version of auth, as it will increase the bundle size for all users, which is already a common concern. In the modularized version, users can decide whether to import it and incur the size increase.