Different versions of Firebase in one bundle break the ability to log Timestamp to Firestore

[appsforartists]

Operating System

MacOS 14.3.1 (23D60)

Browser Version

121.0.6167.184 (Official Build) (arm64)

Firebase SDK Version

10.1.0

Firebase SDK Product:

Firestore

Describe your project's tooling

yarn@4.0.1
vite@5.0.12 (esbuild@0.19.5, terser@5.27.2)

Describe the problem

I'm trying to include a timestamp in a log. It works locally, but I see this error when I deploy:

FirebaseError: Function setDoc() called with invalid data. Unsupported field value: a custom pr object (found in field value.creationTime in document experiments/202402-test/meta/info)

Digging into the bundled JS, I realized that Vite (via esbuild) is mangling my names, and that pr is the value it chose for Timestamp. It doesn't appear that Vite allows you to prevent names from being mangled with esbuild, so I tried changing to terser. terser still mangled the name, but it chose at, so now the error is:

FirebaseError: Function setDoc() called with invalid data. Unsupported field value: a custom at object (found in field value.creationTime in document experiments/202402-test/meta/info)

Steps and code to reproduce issue

import {
  getApp,
} from 'firebase/app';

import {
  doc,
  getFirestore,
  setDoc,
  Timestamp,
} from 'firebase/firestore';

const db = getFirestore(getApp());
setDoc(
  doc(db, 'experiments/202402-test/meta/info'),
  {
    value: {
      creationTime: Timestamp.now(),
    }
  },
);

bundled with vite build

Expected result

Firestore should be resilient to common practices like minification.

I can understand the ambiguity around whether {seconds, nanoseconds} should be treated as a Timestamp or an object literal; however, there are solutions. The most correct one is probably to add a special property like "__firebaseBrand__": "Timestamp" and check it to determine how to store/present a value. Alternatively, you could check value.toString().startsWith('Timestamp'), since that class has a custom implementation of toString.

[appsforartists]

…digging into this further, it seems that there might be two instances of Timestamp in the bundle. Not yet sure why - there's only one copy of the Firebase SDK in my project.

[appsforartists]

at does indeed appear in the distributed source:

// node_modules/@firebase/firestore/dist/index.esm2017.js
class at {
    /**
     * Creates a new timestamp.

[appsforartists]

It looks like an unrelated package had a dependency on an old version of firebase (9.6.1).

Not sure why different parts of my project were resolving different versions of Firebase (and it's already later than I wanted to be working on this tonight), but changing the package.json in the unrelated dependency does seem to fix the issue.

[appsforartists]

Alright, I think this is what happened:

• Most of my Firebase logging is handled by one package in the project (firebreather), which had a correct dependency on 10.1.0.
• Some old demos that are not part of this build had an outdated dependency on 9.6.1.
• The app that was otherwise using firebreather for logging needed to import Timestamp directly from firebase/firestore, but forgot to add an explicit dependency on firebase/firestore to its package.json.
• For some reason, vite serve was choosing the correct version (10.1.0) for both callsites, but vite build was choosing 10.1.0 for firebreather and 9.6.1 for the app.
• Either adding the explicit dependency to the app's package.json or upgrading the unrelated demo package to use the same Firebase version as the rest of the monorepo fixed the issue.

[dconeybe]

Oh that's great. Thanks for getting back to us with the root problem and the fix! I'm glad you got it figured out.