@firebase/rules-unit-testing + vitest throws "Expected first argument to collection() to be a CollectionReference, a DocumentReference or FirebaseFirestore"

[YannicEl]

Describe your environment

• Operating System version: Win11
• Browser version: Node 18
• Firebase SDK version: 9.15.0
• Firebase Product: Firestore

Describe the problem

Issue #6080 seems to be occurring again.
I am using vitest and @firebase/rules-unit-testing to test my firestore securtiy rules. With vitest versions < 0.24.0 everything works great. But since the 0.24.0 release i get the same error as in this issue #6080 Expected first argument to collection() to be a CollectionReference, a DocumentReference or FirebaseFirestore.

I am not sure if this is a vitest issue or a firebase issue. But since issue #6080 is resolved i am not sure if this is a regression or if there is somthing wrong with my setup.

Steps to reproduce:

https://stackblitz.com/edit/vitejs-vite-eugcsg?file=index.test.ts

run npm run dev and there error will show in the console
Emulators don't have to be running for this error to occure.

[milaGGL]

Hi @YannicEl, thank you so much for reporting this issue and narrowing it down to a specific vitest version. I am looking into this and will keep you updated. Happy holidays.

[milaGGL]

Happy new year, @YannicEl . Seems like the entry point of "firebase/firestore" might be sending user's compiler to a different file than rules-unit-testing.

For now, a quick workaround is using "@firebase/firestore" instead. Could you please try that out while we look deeper into the issue?

[laurentpayot]

@YannicEl did you also try this workaround?

[YannicEl]

@YannicEl did you also try this workaround?

I did see and try your workaround when troubleshooting but it didn't work.
Interestingly, I tried it again just now, but instead of forcing the cjs version, I forced the mjs version and it worked.

import { defineConfig } from 'vitest/config';

export default defineConfig({
  resolve: {
    alias: [
      {
        find: /^firebase\/firestore$/,
        replacement: `${__dirname}/node_modules/firebase/firestore/dist/index.mjs`,
      },
    ],
  },
});

So now I have a working workaround, but it would still be interesting to find out what the root problem is. I am guessing that for whatever reason the cjs version of Firestore is loaded instead of the mjs version?

Thank you very much

[YannicEl]

Happy new year, @YannicEl . Seems like the entry point of "firebase/firestore" might be sending user's compiler to a different file than rules-unit-testing.

For now, a quick workaround is using "@firebase/firestore" instead. Could you please try that out while we look deeper into the issue?

Happy new year to you too!

Thanks for the workaround. It works in stackblitz but for some reason it doesn't work in my local project.
I Get the following error.

But that is not that important at the moment because as mentioned in my previous post I have a working workaround now.

Thank you very much

[hsubox76]

I traced the import paths and I think it might be a bug with Vite that they recently fixed.

This next part is maybe TMI and more for my notes:

When you import @firebase/rules-unit-testing it imports firebase/compat/firestore (index.mjs) which imports @firebase/firestore-compat (node.esm.js) which imports @firebase/firestore (node.mjs), which is all correct. It seems to be looking at the exports fields in the package.json the whole time (if found) and prioritizing that over the main field in package.json.

When you import firebase/firestore it right away imports index.cjs.js, and it seems to be looking at the main field in firebase/firestore/package.json and ignoring the exports field in firebase/package.json, which I think is a bug in Vite.

TLDR: I think Vite is pulling in the wrong file because it's not prioritizing exports over main. I see there is a fix for a bug that looks like that in Vite in vitejs/vite#11595 which was merged 4 days ago, so I don't know what Vite release that can be expected in.

[YannicEl]

@hsubox76 Thank you for your investigation. It seems like this fix is going to be released in vite 4.1. I'll wait until it is released and then report if it fixed the issue.

[YannicEl]

i just tested with vitest version 0.30.0 and the issue is fixed.