Adds a demo app to help test and facilitate Firebase Auth API development

[bojeil-google]

Adds a new directory in auth package demo.
3 main steps are needed:

1. config.js needs to be set up in demo/public.
2. Run in demo/: firebase use --add
3. cd .. and yarn run demo

[jshcrowthe]

So this review ultimately has two parts:

• The actual app
• The infrastructure around the app

So the actual app itself looks solid. I love the idea of having a quick and easy way to experiment w/ the different sections of the API. So 👍 from me on that.

The infra around the app I had some larger questions than would make sense for inline comments so I'm putting them here:

Can we leverage the app configured at the top level for testing? We require a production app to do testing, it might make a lot of sense to fold your database.rules.json and firebase.json in with the top level config. That way a user can simply do a yarn test:setup and are configured for the whole app (dev and testing). We would, ideally, also make it so a user doesn't have to manually inject their config (i.e. config.js)

How do we do incremental builds? This works great for a one time through kind of thing, however it'd be nice to reconfigure this for SDK-wide incremental builds (use webpack or something). Is this something we can do here?

[jshcrowthe]

This is going to do a complete rebuild of the dependencies (if needed) which could be quite slow, maybe consider instead just doing yarn prepare?

[bojeil-google]

Done.

[jshcrowthe]

If you are going to do this as part of your demo, maybe consider adding firebase-tools as a devDependency? Then you can just reference it directly as part of your npm bin

[bojeil-google]

Done.

[googlebot]

So there's good news and bad news.

👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there.

😕 The bad news is that it appears that one or more commits were authored by someone other than the pull request submitter. We need to confirm that they're okay with their commits being contributed to this project. Please have them confirm that here in the pull request.

Note to project maintainer: This is a terminal state, meaning the cla/google commit status will not change from this State. It's up to you to confirm consent of the commit author(s) and merge this pull request when appropriate.

[bojeil-google]

Can we leverage the app configured at the top level for testing?
I am open to that. I wanted to contain and isolate Auth changes so I don't affect other Firebase services. We can follow up with enhancements on this after running this by the other owners.

How do we do incremental builds?
I am not sure what you mean by incremental builds. Do you mean building and deploying locally multiple versions of the test app?

[bojeil-google]

Done.

[bojeil-google]

Done.

[jshcrowthe]

Can we leverage the app configured at the top level for testing?
I am open to that. I wanted to contain and isolate Auth changes so I don't affect other Firebase services. We can follow up with enhancements on this after running this by the other owners.

Your proposed config will not break anything in the other tests (all of the other tests don't touch the users property you configure), so I would say lets leverage existing config here first as it complicates the SDK development workflow to have two separate project config steps. But if you can get this in, in the next couple weeks, I'm fine going ahead. Just create an issue to help me track 😄

How do we do incremental builds?
I am not sure what you mean by incremental builds. Do you mean building and deploying locally multiple versions of the test app?

In your demo script, you rebuild the entire SDK before you run the demo. It's just quite costly and you could implement something like webpack-dev-server (see https://github.com/firebase/firebase-js-sdk/blob/master/packages/firebase/package.json#L23) to simplify this and close the feedback loop.

[bojeil-google]

Ok, incremental builds sound like a good feature to have. Let's log an issue to track that and implement it separately. Also I think we can move the hosting config to the root package and leverage yarn test:setup. We'll need to remove the rule: ".read": "auth != null", ".write": "auth != null". I don't think I use it so we should be fine without it.