feat: plugin option to protect production environment

[KantiKuijk]

I was accidentally altering production stuff because I didn't notice the environment variables weren't set. I had to revert to a backup, and thought I should have an option to prevent this from happening in the future.

Description

An extra object can be added to cypressFirebasePlugin where options for the plugin can be specified. The protectProduction option is an object mapping firebase service names to either "none", "warn" or "error". Depending on what is set, the behaviour will be different when te corresponding emulator host environment variable isn't set. "none": same as not setting the option at all, same behaviour as before (backwards compatible) "warn": warns the user in the log but will not error, thus marginally safer for users that actively read the cypress command line logs "error": throws an error thus preventing cypress from starting, thus protecting the production environment

Similar to other PR, I am willing to change docs and tests, if I know this PR has the possibility of being merged, otherwise it would just be wasted time and effort on my part. Also similar, open to changes or different implementations.

[prescottprue]

Love this idea! Thanks for sharing what happened in your case leading you to adding the feature 👏

Updating the docs and tests would be awesome - I can try to get to them early next week if you don't get to it before then

[KantiKuijk]

I have added the tests and documentation: https://github.com/prescottprue/cypress-firebase/pull/1231/commits/b72dec19d05577685846e3130dfad934bea99c5f

Some notes:

If optional chaining is indeed a problem, they should be removed here as well, I don't think the optional chaining is worth having a higher min cypress version if that is the case.

Currently everything is programmed in a backwards-compatible way. If breaking changes are allowed, I would maybe opt for the following two:

1. The default protection setting is 'none', this could be changed to default to 'error'. This could be breaking some workflows, but the fix would just be to alter the config in case the user does not want to address the possibility of production being targeted or has other ways of protecting it (or I guess wants to point to production for staging environments or something similar). The benefit would be a greater default protection for all users.
2. The fourth and fifth arguments for the plugin are both optional, meaning that if only the fifth is needed (plugin configuration) and not the fourth (appoptionsoverride) the fourth has to be given an empty object. This could be done more elegantly by making the AppOptionsOverride also an element in the configuration object, thus making the configuration the fourth element with two optional key-values. This would again and of course be a breaking change, but the fix is again just quick and simple change in config, although the only benefit in this case would be 'elegance'

[prescottprue]

Looks like there is a lint error after I handled a merge conflict, but I don't believe I have access to push to your fork - once you get a chance to update on your end we should be good to release

Thanks again for the feature and your diligence in cleanup to prep for release 👏

[KantiKuijk]

Oh yeah, weird my editor wasn't giving me that linting error at first. I thought I checked the box to allow edits from maintainers. if I find the time for it this summer, I might be looking into adding features for firebase storage, but it looks like that might need another google dependency because firebase storage is just a wrapper around google storage.

[prescottprue]

@KantiKuijk thanks again - needed to do some updates to main before I could get it in

[github-actions[bot]]

:tada: This PR is included in version 4.2.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: