v0.8.0

Firebase is optional now, and that is tested rather than claimed. 0.7.0 added
createHttpLogHandler for backends that are not Cloud Functions, but on one — Cloud
Run with no Firebase packages — /functions failed on require, and once loaded it
dropped every trace id. Both are fixed, and the smoke run now includes exactly that
service. Thanks to Vivek Rao, whose adoption found
the first of it.

Fixed

• /functions could not be loaded without firebase-functions installed, which made createHttpLogHandler (0.7.0) unusable on the backend it was written for. logger.ts imported firebase-functions/logger at module load and logHandler.ts imported onCall the same way, so a Cloud Run service without it failed on require before reaching the HTTP handler. Both are optional peers now, loaded lazily. Where firebase-functions is installed nothing changes — its write() still attaches each trigger's trace id. Where it is not, entries are written as one JSON line each (WARNING and above to stderr, like write()), and the trace comes from the request headers. Reported and fixed by Vivek Rao in #39.
• /functions could not be loaded without firebase-admin either. sourceMapCache.ts imported firebase-admin/storage at module load, for a bucket only older-release maps and attachments need. Storage now resolves on first use, down a chain: firebase-admin if installed (unchanged), else @google-cloud/storage with the bucket you named, else no Storage — current-release embedded maps still resolve, older releases stay minified, attachments are dropped with the entry kept, and one warning says which. hasAttachments is no longer set on an entry whose attachments had nowhere to go. Found by npm run smoke:install, a new check that installs the packed tarball with no optional peers.
• Trace ids were never written on Cloud Run. 0.7.0 built projects/<id>/traces/<trace> from GCLOUD_PROJECT or GOOGLE_CLOUD_PROJECT, and Cloud Run sets neither — so behind createHttpLogHandler the trace was silently dropped. On Cloud Run the project now comes from the metadata server, once, the way Google's own Cloud Run sample does. Without a project the bare trace id is written, which is still a valid trace but does not meet Cloud Run's request log in "show entries for this trace"; the smoke run checks that the two do meet.
• The client's production floor was never applied in a browser. defaultMinLevel guarded on typeof process, which is undefined in every browser even though bundlers fold process.env.NODE_ENV to a literal — so the folded branch was unreachable and every browser build defaulted to DEBUG in production. Seen in a real Vite bundle as typeof process<"u"?"WARNING":"DEBUG". The guard is gone; a runtime with neither the fold nor process throws on the read and is caught.

Documentation

• Without Firebase. The README says what is true now: the browser half has no Firebase dependency, and the server half runs on Cloud Functions, Cloud Run or any Node server. A new section covers what changes without Firebase — authorize, naming a bucket, and which tools are Cloud Functions only.
• A Hono adapter next to the Express one. createHttpLogHandler takes Node's request and response shapes, and Hono wraps them.
• Volume controls: a Vite define: { 'process.env': {} } makes the client's production floor DEBUG. Pass minLogLevel.