Improve the firebase emulator seed handling

[haeser]

During my first contribution when trying to setup the test environment I discovered that the keep alive after seed method is no longer necessary due to improvements on the firebase emulator upstream repo (e.g. firebase/firebase-tools#2224)

As a consequence this PR introduces a way to prepare a local demo setup to

• seed once
• export emulator data including the seed to the folder ./emulator-data
• (all subsequent emulator runs) start with --import

Repeat runs don’t re-run the seeder or need to rely on the workaround @th0rgall found for keeping emulators:exec alive via stdin.resume().

Also adds firebase:demo-reset for a clean start.
Expands demo gardens in the seed (for a nicer international look), and updates dev docs + VS Code tasks + .env.example bits for missing .env variables.

How to test

Run yarn firebase:demo twice and observe that the second run should skip seed
Run yarn firebase:demo-reset and observe that it should start empty.

[th0rgall]

I believe there are Firebase Cloud Functions triggered by Firestore events in the seed script, and I would prefer to keep their effects in the seeded data. If the Cloud Functions are not started, these effects won't trigger.

I assume something like this may exist for latestListedChangeAt, but other similar effects might exist that I don't recall now.

A fix is probably just to also include the cloud functions in demo-seed. The problem is then knowing when to exit. A static timeout might be the simplest. Otherwise, some log scanning could maybe be done to assess whether there is any functions activity going on, or perhaps there is another way to wait for the Firestore-triggered functions to be processed. I'd prefer a simple solution though. Maybe devs could just be required to run firebase:demo-seed, exiting manually when the processing is done, before running firebase:demo.

[haeser]

thanks for the proposal. will look into it. wasn't aware of all these side effects in the first place.

[th0rgall]

Thanks for trying to make this more idiomatic, and adding some extra test data points! I suppose there are performance benefits in not having to re-generate the seeded data every time, and wait for triggers every time. At the same time, I'd like the seeded data to be as representative as possible of the production data, and also easy to regenerate. I left one related comment for now.

I intend to review this further & merge it at some point, for now we're focusing on fixing the last issues before announcing our new Capacitor app though.

[haeser]

Thanks for trying to make this more idiomatic, and adding some extra test data points! I suppose there are performance benefits in not having to re-generate the seeded data every time, and wait for triggers every time. At the same time, I'd like the seeded data to be as representative as possible of the production data, and also easy to regenerate. I left one related comment for now.

I intend to review this further & merge it at some point, for now we're focusing on fixing the last issues before announcing our new Capacitor app though.

No worries. Thanks for taking the time to review. I just wanted to commit what I had in mind while it was fresh from the first time me setting up the project knowingly it would only be a proposal. Your previous solution also worked so there is really no urge here.