Change nativeErrorCode, nativeErrorMessage to be nullable

[jvliwanag]

Description

Update nativeErrorCode and nativeErrorMessage to reflect the possibility of having null values based here and here.

Related issues

Release Summary

Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • Yes
• My change supports the following platforms;
  • Android
  • iOS
• My change includes tests;
  • e2e tests added or updated in packages/\*\*/e2e
  • jest tests added or updated in packages/\*\*/__tests__
• I have updated TypeScript types that are affected by my change.
• This is a breaking change;
  • Yes
  • No

Test Plan

---

Think react-native-firebase is great? Please consider supporting the project with any of the below:

• 👉 Star this repo on GitHub ⭐️
• 👉 Follow React Native Firebase and Invertase on Twitter

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
react-native-firebase	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 1, 2025 8:19am

[CLAassistant]

All committers have signed the CLA.

[mikehardy]

Hmmm 🤔 no denying that they currently can be null in javascript vs the typescript definition

Upstream in firebase-js-sdk the equivalent class has code and message as non-null though https://github.com/firebase/firebase-js-sdk/blob/main/packages/util/src/errors.ts

They have a lot of machinery for making sure the error is associated with a service, and then the code can be specific (and type safe!) or just their Err.GENERIC type, with the message defaulting to a templated version of a specific error or just the string 'Error'

Moving at least closer to that by doing something similar to their GENERIC error code with perhaps something truly generic as a service/detail code combo like 'unknown/internal-error' as the default code vs null, and 'Error' as the default message vs null might start the process of us converging our errors so they may be handled more consistently for people using firebase-js-sdk on web and react-native-firebase on native in same codebase

What do you think?

[jvliwanag]

This doesn't change code and message which have counterparts on firebase-js-sdk really should be non nullable. Only nativeErrorCode and nativeErrorMessage.

[github-actions]

Hello 👋, this PR has been opened for more than 2 months with no activity on it.

If you think this is a mistake please comment and ping a maintainer to get this merged ASAP! Thanks for contributing!

You have 15 days until this gets closed automatically

[mikehardy]

Sorry for the delay here - we're slowly coming to consensus on how to converge our types better with firebase-js-sdk

I think the answer here is:

• alter our type NativeFirebaseError to extend FirebaseError
• by default set the nativeErrorCode and nativeErrorMessage to 'unknown' and 'an unknown error occurred'
• by default set the same into FirebaseError code and message

The alternative, to make these nullable is actually a breaking change for consumers as their build will fail if they're not handling the types - regardless if it is fixing a real bug that nulls could come through or not

So instead of doing a breaking change the wrong way - making things farther from upstream - better to make them closer to upstream so our errors fit into existing firebase-js-sdk error-handling patterns as a drop-in