Cette page propose des conseils et des solutions de dépannage pour les problèmes JavaScript que vous pourriez rencontrer lors de l'utilisation du SDK JavaScript Firebase.
Vous rencontrez d'autres difficultés ou vous ne trouvez pas votre problème ? N'hésitez pas à consulter les questions fréquentes principales sur Firebase pour en savoir plus sur Firebase ou sur des questions spécifiques à un produit.
Vous pouvez également consulter le dépôt GitHub du SDK JavaScript Firebase pour obtenir une liste à jour des problèmes signalés et des solutions de dépannage, et y déposer vos propres problèmes.
Les Admin SDK pour les constructions Node.js ne sont pas compatibles avec le SDK JavaScript Firebase.
Firebase Admin SDK pour Node.js et le SDK JavaScript Firebase sont des implémentations distinctes qui ne partagent pas de définitions d'interface, de classe ni de fonction. Les instances d'objets Admin SDK ne sont pas compatibles avec les fonctions du SDK JavaScript Firebase.
Par exemple, une instance de la FirebaseApp de Admin SDK transmise à la fonction getDatabase du SDK JavaScript Firebase génère l'erreur suivante:
TypeError: Cannot read properties of undefined (reading 'getProvider')
at _getProvider
at getDatabase
Cela est vrai pour l'ensemble de la surface de l'API du SDK JavaScript Firebase, et pas seulement pour Realtime Database.
Il en va de même pour l'utilisation dans l'autre sens. Toute tentative d'utilisation du type Timestamp du SDK JS Cloud Firestore avec Firebase Admin SDK pour Node.js génère des erreurs similaires.
Éviter d'utiliser des versions en conflit du SDK JavaScript Firebase
Plusieurs versions contradictoires du SDK JavaScript Firebase configurées en tant que dépendances dans un projet entraînent des erreurs d'exécution lorsque des instances de SDK sont transmises entre des packages de SDK. Par exemple, l'utilisation de la bibliothèque Data Connect avec une version incompatible de FirebaseApp génère l'erreur suivante:
Error: Component data-connect has not been registered yet
Ce problème est généralement causé par une mise à jour de dépendance d'un des packages du SDK Firebase, mais pas de tous. Cette situation se produit souvent lorsqu'un outil de mise à jour automatique des dépendances modifie un sous-ensemble des dépendances du SDK Firebase dans le fichier yarn.lock ou package-lock.json du projet. Étant donné que de nombreux SDK Firebase JavaScript interagissent entre eux, l'utilisation de différentes versions des SDK entraîne des incompatibilités d'exécution.
Pour résoudre ce problème, supprimez le répertoire node_modules/ et les fichiers yarn.lock (pour yarn) ou package-lock.json (pour npm) de votre projet, puis réinstallez vos dépendances.
Si des erreurs persistent, déboguez davantage le problème à l'aide de la commande npm ls. Les dépendances de votre projet seront journalisées afin que vous puissiez identifier les versions en conflit du module firebase.
Par exemple, le journal suivant montre que package-using-older-firebase importe une version en conflit du SDK JavaScript Firebase:
$ npm ls firebase --all
your-app@0.0.0
├── firebase@11.2.0
├─┬ @angular/fire@19.0.0
│ ├── firebase@11.2.0 deduped
│ └─┬ rxfire@6.1.0
│ └── firebase@10.14.1 deduped
└─┬ package-using-older-firebase@0.1.0
└─── firebase@10.14.1
Des erreurs peuvent également se produire en raison du mélange des instructions require et import de CJS et d'ESM dans votre application. Cela crée plusieurs instances du SDK JavaScript Firebase, chacune distincte de l'autre, ce qui interrompt l'interopérabilité du SDK JavaScript Firebase.
Augmentez le niveau de verbosité de votre bundler de choix pour déboguer ce scénario. Par exemple, vous pouvez utiliser l'indicateur d'analyse esbuild à cette fin.
Assurez-vous que les service workers sont groupés
Les travailleurs de service sont souvent créés à partir d'un pipeline distinct du reste d'une application Web et ne sont pas inclus dans la configuration par défaut des outils de compilation tels que Webpack.
Si vous utilisez la version modulaire du SDK JavaScript Firebase dans votre worker de service, veillez à configurer votre outil de regroupement d'applications pour qu'il inclue le fichier source du worker de service. L'exemple suivant utilise npx pour regrouper le service worker firebase-sw.js dans le répertoire src du projet:
npx esbuild ./src/firebase-sw.js --bundle --minify --main-fields=webworker,browser,module,main,default --outfile=public/firebase-sw.js
L'activation d'un service worker qui n'est pas groupé échouera s'il source des modules ES d'importation qui ne sont pas compatibles avec les service workers ou des fichiers qui n'existent pas dans le champ d'application du service worker. Parfois, ces échecs sont silencieux et difficiles à déboguer.
Pour en savoir plus sur le regroupement de la version modulaire du SDK JavaScript Firebase dans votre application, consultez Utiliser des outils de regroupement de modules avec Firebase.
Vous pouvez également éviter d'avoir à regrouper les SDK en important les bundles de SDK compat
Firebase JavaScript à partir du CDN:
// Give the service worker access to Firebase Messaging.
// Replace 10.13.2 with the version of the Firebase JS SDK you're using
// in your app.
importScripts('https://www.gstatic.com/firebasejs/10.13.2/firebase-app-compat.js');
importScripts('https://www.gstatic.com/firebasejs/10.13.2/firebase-messaging-compat.js');
// Initialize the Firebase app in the service worker by passing in
// your app's Firebase config object.
// https://firebase.google.com/docs/web/setup#config-object
firebase.initializeApp({
...
});
// Retrieve an instance of Firebase Messaging so that it can handle
// background messages.
const messaging = firebase.messaging();
Utiliser FirebaseServerApp avec l'affichage côté serveur
Le SDK JavaScript Firebase était à l'origine conçu pour s'exécuter dans des environnements de navigateur. L'introduction de frameworks d'affichage côté serveur (SSR) pousse l'utilisation des SDK vers de nouveaux environnements d'exécution. Ces environnements d'exécution fournissent un sous-ensemble d'outils et d'API que les navigateurs Web fournissent.
Par exemple, certains SDK Firebase nécessitent le stockage en cache des données avec IndexedDB, une API réservée aux navigateurs. Firebase Auth peut nécessiter une interaction de l'utilisateur dans certains flux de connexion, ce qui est impossible dans les environnements de serveur headless. App Check s'appuie sur des heuristiques de navigateur pour valider l'utilisateur avant de créer des jetons App Check.
Lorsque vous utilisez le SDK dans ces nouveaux environnements, utilisez FirebaseServerApp, une nouvelle variante de FirebaseApp qui permet de précharger l'instance Firebase SSR avec les données collectées côté client.
FirebaseServerApp accepte deux paramètres:
- Jeton d'ID d'authentification: si fourni, Firebase Authentication connecte automatiquement un utilisateur précédemment authentifié, ce qui peut s'étendre sur une session au-delà de la division CSR/SSR.
- Jeton App Check: si fourni, le jeton est utilisé par les autres SDK Firebase sans qu'il soit nécessaire d'initialiser une instance d'un client App Check (qui n'est pas compatible en dehors des environnements de navigateur). Cela débloque la prise en charge du SSR pour les produits pour lesquels App Check est activé, tels que Cloud Functions, Data Connect, Cloud Firestore, Realtime Database et Vertex AI.
Consultez Simplifier le développement d'applications SSR avec FirebaseServerApp pour voir un exemple d'utilisation de FirebaseServerApp dans Next.js.