Running locally doesn't read/write the latest data

Hello, This is a great tool! So, thanks!

I ran into this problem when I was figuring out how this package works, and it made it really difficult to figure out what I needed to do!
I also don’t have a solution to it, other than a lot of emulator reloads.

I tried running a migration against my local emulators, but it only ever returned 1 document.
I exported the data from my emulators, restarted them and re-imported the data, then the migration found the additional documents.
I think I had 1 document in the collection I was migrating when I first loaded the emulators and dry-ran the migration. I then added more documents for more testing, which it never picked up.
I had to export the new data from the emulators, restart the emulators, then reimport the data for it to be picked up by fireway.

Also, the saved migration details seemed to disappear, but still function for fireway.
So, I would run a v0.0.1 migration against the local emulators. It would do its thing.
No new collection called fireway would turn up in the emulators, however fireway would no longer run that migration version.
I looked through all my firebase projects in case it had leaked to a dev/prod project, however I didn’t see it in any of them.

Once I confirmed my migrations (with lots of emulator restarts), everything ran fine on my dev/prod projects.

[kiptoomm]

Fair enough. In any case, this feature would help:

the output could show the last migration that was executed

[ylno]

I have the same or a very similar problem. I do not see the changes that fireway makes in the emulator. Unfortunately exporting and re-importing the emulator data does not help me either. The state of the db remains the same.

When I run fireway twice in a row, the shell output looks correct: the first time the migrations are executed. The second time fireway recognizes that the migrations have already run. But the view of the data in the emulator ui still shows the old data.

Until recently I did not have these problems and could test the migrations locally. A colleague who has an identical setup cannot reproduce the problem. For him, the data is changed correctly.