Repository navigation
test: exercise real firebase-functions majors in CI, not just the pinned devDep #333
Description
Context
#310 happened because firebase-functions@7.x changed the emitted wrapper shape (rest-param functions, run.length === 0) and nothing in CI noticed: devDeps pin firebase-functions: ^4.9.0, so the suite only ever runs against 4.9.0 while the peer range allows >=4.9.0.
The regression test added in #311 simulates the v7 shape with hand-built mocks. That's the right thing for a unit test, but mocks encode our belief about the dependency's shape; if a future major changes the shape again, the mocks stay green while wrap() breaks for users, same failure mode as #310.
Proposal
Add a CI matrix dimension installing multiple firebase-functions majors (at minimum: lowest supported 4.9.0 and latest 7.x) and run the unit + integration suites against each. Alternative: a second install step swapping in latest before a re-run.
Detection-focused: the goal is that the next arity/shape drift in firebase-functions fails a build here instead of shipping.
Activity
cabljac commentedon Jul 23, 2026
Some findings from investigating this locally, and a proposed shape.
What we verified: on firebase-functions@7.2.5 all the wrap()/wrapper-shape tests (the ones this issue exists to protect) pass. The only failures are the two #mockConfig tests, because functions.config() is removed in v7 (typed
never, throws at runtime). Separately, compiling the specs against v6/v7 typings fails on a nested @types/express lib-check conflict, so a naive matrix leg can't even build without a skipLibCheck or devDep policy change.Proposed shape, three parts:
Compile-then-swap rather than recompiling per version: compile specs once against the pinned 4.9.0, swap in the newer firebase-functions, run mocha on the compiled output. This mirrors how firebase-functions-test@3.4.1 misdetects v2 callables #310 actually hit users (their compiled code, new runtime shapes underneath) and sidesteps the type conflicts without touching tsconfig policy.
Don't skip the mockConfig tests on v7, assert the failure: mockConfig should detect firebase-functions >= 7 and throw a clear "functions.config() was removed in v7, migrate to params" error, and the v7 leg asserts that throw. Skipping would make the matrix pretend mockConfig works on v7 when it can't; with the throw, the >=4.9.0 peer range's promise becomes true again, everything either works or fails loudly with migration guidance.
Pinned majors gate PRs, floating latest doesn't: required per-PR legs for 4.9.0 and ^7, plus a scheduled canary against latest that doesn't block merges. Otherwise the day v8 ships, every open PR here goes red for unrelated reasons.
Scope: unit job only to start, the integration job exercises the same wrap surface through the emulator for no extra signal.
That makes this three small PRs: the mockConfig throw + tests, the matrix, the canary job.
IzaakGough commentedon Jul 27, 2026
Thanks for raising this! We will investigate as soon as possible.