Migrate from the Local Emulator Suite

If you decide to try Fireemu, it reads your existing firebase.json, serves the same default ports, and accepts the official command names, so most projects move by changing one command. Before you switch, check that the products you use are on the supported list: the Local Emulator Suite also serves App Hosting, Data Connect and Extensions, which Fireemu does not, and Hosting and the Realtime Database are partial.

Steps

1. Install Fireemu and create fireemu.toml that references your firebase.json:

   npm install --save-dev fireemu
   npx fireemu init --firebase-json firebase.json

   Keep profile = "strict", the default.

2. Replace the commands:

   Before	After
   firebase emulators:exec "npm test"	fireemu exec -- npm test
   firebase emulators:start	fireemu up

   fireemu emulators:exec and fireemu emulators:start also work, and exec accepts the official quoted-script form.

3. Run your tests.

When a test fails under strict

A test that passed on the official emulator but fails under strict often shows behavior your application would also meet in production. Fix the test or the application, or relax only the specific setting below, rather than switching the whole profile to emulator.

• Unsigned emulator ID tokens. @firebase/rules-unit-testing’s authenticatedContext() and the client SDK’s mockUserToken work under strict by default. Set auth.allowUnsignedIdTokens to false to disable their fallback on the Security Rules surfaces and test production’s refusal of them. For a refusal test, use the SDK helper’s default iat: 0 / exp: 3600 with a clock after expiry; fireemu-issued tokens that pass normal verification are still accepted. Use auth.idTokenSigning = "session-rsa" to refuse all unsigned ID tokens. See Unsigned mock ID tokens.
• Named databases. Declare each named database in the firestore array of firebase.json, with its rules and indexes files, or create it through the Admin API, as production needs it created. A database created at run time has no Security Rules until you load some for it (see Firestore).
• Composite indexes. Queries are checked against your declared indexes, as production checks them. Declare the index a query needs in firestore.indexes.json, referenced from firebase.json.
  • A query whose index is missing is refused with FAILED_PRECONDITION and a link to the index, as in production.
  • A composite index with a single field is refused when the file loads, as firebase deploy refuses it: use fieldOverrides.
  • To keep running such queries while you add the indexes, set firestore.missingIndexes to "report": the query runs and each missing index is reported once per database on standard error, with production’s refusal text and the firestore.indexes.json entry. productionExact does not change this key.
  • For OR queries, supplementary standard-error diagnostics list all distinct missing branch indexes, so you can add their definitions together; strict still returns the existing SDK error with the first index creation link, and the emulator profile still serves the query. Repeated suggestions are deduplicated and the diagnostic cache is bounded.
• Settings that mirror your production project. Set them to match it instead of switching the profile:

Setting	What it does under strict
auth.improvedEmailPrivacy	Email enumeration protection, on for a new production project. Set false only if your production project turned it off; sign-ins then answer EMAIL_NOT_FOUND and INVALID_PASSWORD as the official Auth emulator does.
auth.mfa	Your project’s multi-factor configuration. strict starts with SMS and TOTP enabled; productionExact starts with multi-factor off, as a new production project does. See Authentication.
firestore.enforceLimits	Production always enforces the Standard edition query limits. false lets queries pass that production refuses, so leave it on unless you have a specific reason. Under strict it switches only the query limits.

Differences from the official CLI

• A failed --export-on-exit makes the run exit 1 when the command succeeded. The official CLI only warns and exits 0; Fireemu differs so that a CI job that depends on the saved data cannot pass without it.
• On Unix, a discovered fireemu.toml or firebase.json is loaded only when its owner is trusted. See Configuration files.
• Under strict, a project without Security Rules behaves as a production project without a rules release: client requests are refused. See Security Rules.