Repository navigation
Release process: smoke render the packed build in CI to catch browser-only regressions #848
Description
A minimal Next App Router (turbopack) app and a Vite app that render a data hook against the packed tarball in CI, failing on the #759 crash class.
Split out of #765 (item 7) so it is not lost when that issue closes.
Why this is worth more now than when #765 was written
What it covers
- App Router crash: reactfire 4.2.4/4.2.5 throw "dynamic usage of require is not supported" on the client #759's class. Verified against the published tarballs (table in the comment linked above): the ESM entry on 4.2.4 and 4.2.5 throws
Calling `require` for "react" in an environment that doesn't expose the require function, and 4.2.6 loads clean. - Browser and bundler-only failures that do not reproduce on a Node import. This is what a render adds over a load, and it is the part no proposed check has ever covered.
What it does not cover
require('reactfire'). Next and Vite apps import ESM, whilemainis stilldist/index.umd.cjs.- Publishing. If it lives in a demo app's CI it has no
needs:edge into this repo'spublishjob, so it informs a release rather than gating one.
Where it should live
The planned home is the V5 demo app's CI, which does not exist yet. It could equally ride example/ once #784 is fixed. Worth deciding before building, since it determines whether this is blocked.
Cost
Roughly a day, plus CI minutes on every PR and added flake surface. That tradeoff is why it was not built alongside the rest of #765.
Related
#765 (parent), #759 / #760 (the regression this catches), #766 (the gate that shipped), #784 (example/ is currently uninstallable)
Activity
jhuleatt commentedon Oct 30, 2026
Instead of this being a CI process, could you add a step-by-step publishing guide to https://github.com/FirebaseExtended/reactfire/blob/main/.github/CONTRIBUTING.md that includes checks that need to be run? That way, we can just point an agent at the guide instead of having to build out another CI pipeline. Would that cover the concerns brought up here?
tyler-reitz commentedon Oct 30, 2026
Yes, that covers it. #849 adds a "Publishing a release" section to CONTRIBUTING.md, and step 3 is the browser smoke test this issue was after: render the
-expbuild in production Vite and Next.js App Router apps before tagging. Following the steps against 4.2.4 catches the #759 crash in both apps, and 4.3.0 passes. The one thing a guide gives up is enforcement, since nothing stops a tag without the check, but a CI job in a separate demo app wouldn't have gated publishing either.