[cloud_functions] Support for cloud functions emulators

[DavoBR]

Description

This PR allow you configure to dev environment to use cloud functions locally

Related Issues

I have not found any problems related to this RP, this change arose with the need to use this plugin in a local environment before deploying the function

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
• All existing and new tests are passing.
• I updated/added relevant documentation (doc comments with ///).
• The analyzer (flutter analyze) does not report any problems on my PR.
• I read and followed the Flutter Style Guide.
• The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
• I updated CHANGELOG.md to add a description of the change.
• I signed the CLA.
• I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

• Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
• No, this is not a breaking change.

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

[collinjackson]

Thanks for the PR! Ideally we'd have an integration test for this change, but I think we'd need to either teach our CI to run an emulator (which wouldn't support testing in places like Firebase Test Lab) or we'd need to set up a public running instance of the emulator. I'm ok with landing the emulator support without an integration test if we don't want to maintain that infrastructure right now.

[Salakar]

Thanks for the PR! Ideally we'd have an integration test for this change, but I think we'd need to either teach our CI to run an emulator (which wouldn't support testing in places like Firebase Test Lab) or we'd need to set up a public running instance of the emulator.

@collinjackson If it helps, we have a live API mocking the functions emulator for React Native Firebase which you can use if you'd like, here's the specific test: https://github.com/invertase/react-native-firebase/blob/master/packages/functions/e2e/functions.e2e.js#L79-L90

The mock emulator endpoint just returns back the region and the fnName as data so it can be used to validate that the correct region & fnName are being set.

I'd need to update it to work for the Firebase Project ID you're using for integration testing (but this is a 2 min change & deploy - so can do it pretty quickly). Or we can look at sharing our Firebase project for integration testing - ours is quite well set up to test various scenarios across Firebase services with various rate limits whitelisted.

---

Another consideration here is that localhost/ 127.0.0.1 on Android emulators is the Android device localhost - when actually 10.0.2.2 (proxy to the emulator host machine) is needed. The Firebase docs and Firestore emulators don't mention this and say to use the http://localhost:5000 address - so this should either be documented or automatically converted internally to the proxy address, we took the converting approach, here: https://github.com/invertase/react-native-firebase/blob/master/packages/functions/lib/index.js#L83-L90

Looks like there are some param docs for this already:

[collinjackson]

Please update the version in pubspec.yaml to match the changelog version (0.4.1)?

[DavoBR]

Hi @collinjackson,

About your comment of my IDE, i am using VSCode, what should be the correct configuration to meet the standard used here?

[collinjackson]

Hi @collinjackson,

About your comment of my IDE, i am using VSCode, what should be the correct configuration to meet the standard used here?

I'm not sure. Asterisks and hyphens are both valid bullets in Markdown. I would just turn off the automatic formatting of Markdown if you can. So far this is only showing up in your PRs and I don't see any mentions in the Flutter issue tracker so I'm not sure how widespread this issue is.