Convert e2e unit tests to use Jest

[hsubox76]

E2E tests have been broken since upgrading TypeScript from 4 to 5. The reason is that between TypeScript 5.2.2 and TypeScript 5.3.3, an internal property on sourceFiles, resolvedModules was removed, and moved to Program. See PR: microsoft/TypeScript#55790 This caused karma-typescript, which we use for the karma tests, to break as it was depending on that field to find modules and determine if it should bundle files. karma-typescript is deprecated and no longer maintained so we can't get a fix from it even though we know the problem.

In light of this, I'm migrating our E2E tests from karma to Jest.

Pros:

• a lot of our users use Jest (in JSDOM mode) so this will catch SDK incompatibilities with it early
• it's maintained

Cons:

• Since Jest uses JSDOM and not a live headless browser, these tests don't catch any conflicts with real browser APIs
• Also due to some things missing in JSDOM, we need to do some patches, polyfills, and mocks, and reduce some functionality

Details

• Had to mock some browser APIs directly (service worker related) before calling getMessaging(), or else there would be an error
• Had to turn off useFetchStreams on Firestore tests as JSDOM does not handle fetch readable streams well. There's no public API to turn it off in compat so I had to do it pretty hacky.
• We had some special 5000ms timeouts on some tests because karma's default was 2000ms which wasn't enough. Jest's default is already 5000 so I got rid of the special settings on those tests.
• Jest running in Node allows it to easily read process.env.APP_CHECK_DEFAULT_TOKEN in the config so we don't have to do the convoluted custom context.html that karma required
• Did not touch the webpack build tests, those are still valuable as is, and still working (they test if the project builds in webpack without error)

[changeset-bot]

⚠️ No Changeset found

Latest commit: 2ca2cc2

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[google-oss-bot]

Size Report ¹

Affected Products

No changes between base commit (cb4309f) and merge commit (f7a18ca).

Test Logs

• Base (cb4309f): https://github.com/firebase/firebase-js-sdk/actions/runs/12167009301
• Merge (f7a18ca): https://github.com/firebase/firebase-js-sdk/actions/runs/12187476979

1. https://storage.googleapis.com/firebase-sdk-metric-reports/YMbJ2wuk5a.html

[google-oss-bot]

Size Analysis Report ¹

Affected Products

No changes between base commit (cb4309f) and merge commit (f7a18ca).

Test Logs

• Base (cb4309f): https://github.com/firebase/firebase-js-sdk/actions/runs/12167009301
• Merge (f7a18ca): https://github.com/firebase/firebase-js-sdk/actions/runs/12187476979

1. https://storage.googleapis.com/firebase-sdk-metric-reports/pyqeE6NPUB.html

[Smrtnyk]

Have you guys considered vitest https://github.com/vitest-dev/vitest?
it is fast and well maintained, where jest is not seeing much activity lately.
It even has a browser mode where unit tests run in real browser.
Just wanted to mention this, as a long time user of firebase software

[dlarocque]

💥

[hsubox76]

Have you guys considered vitest https://github.com/vitest-dev/vitest? it is fast and well maintained, where jest is not seeing much activity lately. It even has a browser mode where unit tests run in real browser. Just wanted to mention this, as a long time user of firebase software

Thanks! Yes, I considered vitest. We might migrate to it eventually if it becomes more popular, which it seems to be on its way to becoming. I went with Jest because it's currently the most commonly used, users often report issues with it, and so catching errors in it will impact the most users. If vitest grows in popularity I would love to move over, especially for real browser testing. We could also maybe do both, will put it in our wishlist.