Firenook releases

0.2.0: The first release for public use

Fri, 23 Oct 2026 11:10:45 GMT

A stable version. npm install firenook and a bare npx firenook get 0.2.0 on any Node from 20 up; previews keep their own versions, and a preview install is told about 0.2.0.
firenook init in a terminal. One screen with every choice made (the project id, the emulators on their usual ports, TypeScript, JavaScript or no Functions, the coding agents, the set-up), then the installs, Firenook pinned, the first build and the emulators started in the same terminal. TypeScript is the default, from the official template. Without a terminal it writes the files and prints the commands that finish the set-up; --yes runs them.
TypeScript compiled as you save. --build runs each codebase's own build:watch beside the engine and starts it after the first compile; errors show in the log. emulators:exec --build runs build once and no test when it fails.
Ordered and range queries. An order-preserving field index serves orderBy, range filters and cursors on a top-level field, and checks equality on other fields before a document is read; a batch get writes stored documents straight into the reply. The six query shapes the official emulator answered faster in the 0.2.0-next.6 benchmark are now 1.8 to 8 times faster than it (orderBy an integer, limit 20: 12.0 ms against 96.3 ms). A store an earlier release wrote builds the index once on its first open (7.4 s for 211,202 documents, 49.3 s for 2.7 million on the benchmark server); an earlier release opening a 0.2.0 store rebuilds its own index.
Node 22, 24 and 26. Older is refused with how to switch; an odd or newer major starts with a warning; a codebase whose engines.node asks for another Node is warned about, as the official emulator warns. doctor reports the Node and every problem.
Older Linux. The engines need glibc 2.28 (RHEL 8, Debian 10, Ubuntu 20.04, node:24-slim and later) instead of 2.39; Alpine and older systems are told what they lack.
Security Rules as the official emulator applies them. A gRPC request without an Authorization header is signed out, not the owner. @firebase/rules-unit-testing works. A database firebase.json does not list follows the default database's rules; a Storage target with several buckets applies its rules to each; a denial names the rule line.
Nothing reaches production. The console's snippets (Python Storage, Apple Firestore, Tasks and Eventarc everywhere) and emulators:exec, which now sets the official variables for the running emulators only. The demo credentials of exec and of the Functions workers take their token from the emulators: no firebase-admin release tested asked Google for one, and a function no longer falls back to the developer's own gcloud login.
Functions. Params' defaults, .env.<alias>, the .env values at discovery, the project firebase use chose, warnings for triggers on services that do not run, functions:invoke --help, ext:vendor --offline, the Firebase login on Windows.
REST. createDocument works, and every v1 method answers as the official emulator does (the differences kept are listed in COMPATIBILITY.md).
Starts and stops. Two suites with one project id; Firestore closed after browser sessions; a killed launcher stops its engine, which saves the data; --import without metadata and a bad indexes file warn; firebase.json found from a folder inside the project; localhost and ::1 bound as officially.
Polish. init --force keeps your rules, init --adopt keeps your formatting, --ui comes before ui.enabled: false, counts agree with their nouns, every service's lines reach the screen, CI=false is not CI.

Full notes

0.2.0-next.8: The Firestore tree at once, code in colour, npx on any Node

Wed, 21 Oct 2026 13:20:31 GMT

npx firenook gets this release on any Node from 20 up. On any Node but 24, npx firenook init installed firenook@0.0.0, the placeholder that held the name before the first release, with its old advice: every release declared engines.node as >=24 <25, and for a bare name npm takes latest only when its engines admit the running Node, and otherwise the highest version that is not a preview. engines.node is now >=20, npm's own floor. The emulators still need Node 24, and now say so with the way to switch: "the emulators need Node 24, since your Functions run on it; this is Node 26.9.0. Switch to Node 24 (with nvm: nvm install 24) and run it again". init and the other commands run on any Node.
The Firestore tree at once. The console's tree said "Mapping the database…" for minutes on a large store. Its first walk now reads the collection index instead of the documents (37 s instead of 133 s on 2.7 million documents), a clean stop saves the tree with the data so the next start shows it in under a millisecond, and while a walk runs the root collections are listed with their counts. After a crash, or any change to the data since the stop, the tree is mapped again on first use.
Code in colour. Every code block in the console (the Connect dialog, a document as code, a request as code) is coloured with the editor's palette, in the language it is: the Flutter, Swift, Kotlin and Java snippets are no longer marked as JavaScript, and environment variables read as .env lines.
The console behind local proxies. Any name under localhost, such as portless's my-app.localhost, is answered like localhost; docs/console.md says how to reach the console through portless. .local and custom domains still need --allowed-hosts.

Full notes

0.2.0-next.7: Data kept without a seed, coding agents set up in one command, 54 MCP tools

Tue, 20 Oct 2026 18:56:32 GMT

A project with no seed keeps its data. --resume-state needed --import, so a project made with firenook init could not keep its data between runs. Now it needs only a state directory; data started without a seed records an empty one, and a start that mixes the two up (a seedless state given --import, or a seeded one started without it) is refused with the way on, nothing changed.
--keep-data is short for --state-dir ./.firenook/state --resume-state, with or without --import. Keeping data stays opt-in, so --import ./data alone still starts from that data every time. init prints its start command with --keep-data.
firenook mcp add gives the project's coding agents the MCP server: it writes .mcp.json (Claude Code), .cursor/mcp.json and .vscode/mcp.json for the agents it finds, keeping every other server, with --dry-run, --agent and --force. A second run changes nothing. init offers it once in a terminal; init --adopt lists it in its plan. The terminal's ? help names it.
54 MCP tools, up from 19. The function calls and the log (with each call's error and stack trace, and a replay), Security Rules (the rules in force, whether a request as a given user is allowed and which line decided, recent denials), Auth tokens and claims, Storage files (read, upload, delete, copy, move), Eventarc, Extensions, Pub/Sub topics and a backlog peek, Cloud Tasks, schedules, Firestore counts and collection-group queries, and a reset that asks for the project id before it clears more than one service. The new tools use the console's API, so they need the console on (the default). A {"$timestamp"} finer than a millisecond now keeps its precision when a tool writes it.
firenook mcp with no arguments uses the one running suite, so an editor's install link needs no project id; with two running, it asks for --project.
The console's Connect dialog has a Coding agent tab: the setup for Claude Code, Cursor, VS Code and any other agent, "Add to Cursor" and "Add to VS Code" install links, and when an agent last called.
Functions start in under a second, not seven. Discovery waited about 6 s for the SDK's discovery server to exit, kept open by an idle keep-alive connection; it now takes about 0.2 s. On the acceptance host, a project with seven functions and every emulator is ready in 0.78 s against 6.82 s.
Timestamps are stored to the microsecond, as in production: a finer value is rounded down at write, so the export no longer refuses it, and the export rounds down any finer value an earlier release saved.
The Functions log line's duration prints 1.6ms, not 1.6076249999999999ms.
The console's document panel reads a bare id in doc= against the open collection instead of crashing.
Checked against 0.2.0-next.6 on the acceptance host with the same data, instead of a new paired run against the official emulator, since no measured path changed: imports, resumed starts, writes, listener delivery and the query shapes match within run-to-run noise, and memory is 11 MB higher once ready (docs/benchmarks.md, benchmarks/next7-regression.json). The slow start the 0.2.0-next.6 run saw on a freshly copied state directory is the copy's pending writes reaching the disk, not Firenook.

Full notes

0.2.0-next.6: Data closed on stop, starts in milliseconds, the store's size

Sun, 18 Oct 2026 12:39:19 GMT

A stop closes the data. Since 0.2.0-next.3 a stop left Firestore's store file marked open (and Storage's since 0.2.0-next.4), so every start after a stop repaired it first. The console's change feed, schema index and Overview count held the store they observed, Storage held a Firestore handle, and the console's whole-database walks ignored the stop. A stop once ready, or while starting, now closes Storage, then Firestore; one that cannot close a database is reported as a failed stop.
A killed engine is no stop. The screen said "stopped … everything is kept" whenever a stop was asked for and the engine then ended, even by a kill. Now it says the stop did not finish and that the next start checks the data first; plain mode says the same in one line.
Saved data opens in milliseconds. The documents' count is saved with every commit instead of decoding every document at each open: a 32.6 GB store of 2.7 million documents opened in 146 s and now in 67 ms, a 4.3 GB one in 1.4 s and now in 63 ms. The first start of data an earlier release wrote counts once and saves the result.
firenook state:inspect --state-dir DIR shows what a stopped store's file holds, table by table, and how much of it is free.
firenook state:compact --state-dir DIR returns a stopped store's free pages to the disk, copying the file first (a clone where the file system has one; --no-copy skips it). Every document stays as it is. On the 32.6 GB store: 32.60 GB to 27.79 GB in 16 minutes.
The console Overview's Firestore card shows the store's size on disk.
The old documents table is cleared once its documents are copied to the current layout; stores first written before 0.1.0-next.3 carried a dead copy of every document.
Published straight to latest. The release workflow can now publish the CLI to latest in its one trusted publish, and this release used it. npm sets one tag per publish, so the CLI's next stays on 0.2.0-next.5 until it is moved by hand, and a preview install, which follows next, is not told about this release until then.

Full notes

0.2.0-next.5: Saved data: a quick seed check, quick repairs, clean stops

Sat, 17 Oct 2026 17:45:59 GMT

The seed check reads file details. Saved data (--state-dir with --resume-state) is picked up after comparing each seed file's size and times with the record made at the import (native-seed.json, beside the receipt); only a file whose details changed is read. On a 7.8 GB seed the check went from 23 to 26 s to under a second.
Files operating systems write never block a start: .DS_Store, ._*, Thumbs.db, desktop.ini, __MACOSX and the like are ignored, and the Storage import skips ._* files.
A first import hashes the seed beside the import, on worker threads, instead of reading it twice in full around it.
A changed seed names its files, and firenook state:adopt-seed --state-dir DIR --import DIR keeps the data with the seed as it is now (the previous receipt is kept beside the new one).
Quick repairs. The store's durable commits save what a repair needs, so a start after a crash or a killed process repairs in moments instead of reading the whole store. --durability per-commit leaves it out to keep its commit latency.
A repair shows its progress: the Firestore row reads repairing NN% with the store's size, and the plain log prints how far it has got.
A stop while starting closes the data cleanly. Ctrl-C, SIGTERM, a closed terminal and the launcher's pipe are listened for from the first moment: a seed check or a repair is abandoned with nothing opened, an import into a fresh run's directory ends at once, one into saved data finishes first. Nothing is exported before the emulators served anything.
The start-up limit counts quiet time: a start that reports as it goes, such as a long repair, is not stopped after 20 minutes.
Saved data from 0.2.0-next.4 and earlier is checked in full once, then recorded; data saved by 0.2.0-next.5 stays readable by 0.2.0-next.4. The state format is unchanged: the record is a new file beside the receipt.

Full notes

0.2.0-next.4: The terminal UI

Sat, 17 Oct 2026 13:58:57 GMT

The terminal UI. In a terminal, emulators:start draws its own screen: a start-up card with a row per service filling in with how long it took and what it holds, the ready summary (the console's address, the ports, the start-up warnings once, a newer release), the log with a line per call, its duration and cause and the function's own output under it at its level, reloads and failed saves with the code around the error, and a footer pinned to the window's last line with the keys: o console, r reload, e export, w warnings, ? keys, q (or Ctrl-C) stop, saving first.
A start that cannot run says what went wrong, how to fix it and what became of the data, and exits 1. A taken port names the program holding it, the command that stops it and a free port for firebase.json; saved data refused because its seed changed says so, and names a .DS_Store Finder wrote into the seed. Functions that do not load leave every emulator running and load again on the next save.
The plain output is unchanged. Pipes, CI, log files, emulators:exec, --plain, FIRENOOK_PLAIN=1 and TERM=dumb get the same lines as before, All emulators ready alone on its line. NO_COLOR keeps the screen without colour; terminals without its symbols get plain characters (FIRENOOK_ASCII=1 asks for them).
The release check asks the npm registry for firenook's version tags at most once a day, in the background, and shows a newer release on the next start with the install command for the project's package manager. It is off in CI, in the plain output and with FIRENOOK_NO_UPDATE_CHECK=1 or NO_UPDATE_NOTIFIER=1.
Engine. firenook suite --terminal-events prints FIRENOOK_EVENT <json> lines in place of the human lines they stand for (DESIGN.md, the terminal). Refused saved data now says what changed in every output: an unfinished import, another state format, another project, other buckets, another seed path, or the seed's content.
Journeys. The New user journey waits for the form to empty before typing the next user, which a reset on the page's answer had wiped once.

Full notes

0.2.0-next.3: Firenook's own console, and Google's Emulator UI gone

Sat, 17 Oct 2026 13:06:26 GMT

The console. /console on the UI port covers every service the suite runs: Firestore data, queries, explain and security rules; Authentication users, activity, the inbox of codes and links, and settings; Storage files and rules; Functions with their invocations, schedules and load log; Extensions; Eventarc; Pub/Sub; Cloud Tasks; Logs; and an Overview with each section's health, recent problems, snapshots and resets. It follows the engine live over one connection per browser and works offline.
Google's Emulator UI is gone. Every feature of the Emulator UI 1.15 has a console screen (support/console-parity.md), so nothing is downloaded and the UI port serves the console alone. The port's root and the official UI's addresses (/firestore/…, /auth, /storage/…, /extensions/…, /logs?q=…) lead to the console's page for the same thing. /api/config, the logging WebSocket and the Firestore Requests socket are unchanged.
CLI. firenook setup downloads nothing and stays so that scripts which run it keep passing. The engine's --ui-archive argument is gone; the npm package never passed it by hand. doctor no longer reports asset files.
Functions. A call's last log lines no longer appear after its own Finished "…" line. The source watcher waits for a second of quiet after the last change (at most five after the first), as the official CLI does, and an extension's parameter file is read only once it holds still, so a save caught between truncate and write no longer reloads an instance with every value at its default.