Great! Add Rob as the reviewer as he's the MasterOfGenerators™

You'll need a way to write out the custom auth.firebase template instead of the single auth template we have now. You could do a check that if the provider has its own template, write it out, otherwise use the generic auth.js one we already have.

I've sent a fix, unfortunately I have issues testing it ( the template file appears when I use the rwt kit, but when I start the generate command for some reason it disappears and therefore, cannot be found ). I'll have to leave testing to one of you I'm afraid :-, this is out of my reach.

I start the generate command for some reason it disappears and therefore, cannot be found ). I'll have to leave testing to one of you I'm afraid :-, this is out of my reach.

I've experienced it too, I usually run yarn to install things, and then yarn rwt cp ../<path>/<to>/<repo>

Sometimes the rwt command blows up.

I can definitely test it though!

ah thanks @peterp that'd be nice!

Good to know it's not an isolated issue ( isolated in front of my computer screen x) ). Both the copy and copy:watch have proved to be unreliable, I really think it was an awesome way to get people to contribute so I hope it'll be fixed soon enough :). Either way, brutally setting up symlinks can do a dirty trick to make do, but I'm happy to trade it for your solution.

@cannikin no problem, makes sense :) sent the fixes for review

Awesome! And you've tested both the firebase generator and at least one of the others to make sure everything still runs smooth?

Awesome! And you've tested both the firebase generator and at least one of the others to make sure everything still runs smooth?

@cannikin I have tested auth0, still runs smooth ;), unfortunately I met issues while testing firebase:

• I can run the build
• I can copy the framework to my test project with rwt without issue
• all files are here in ./dist
• when I run the auth generator for firebase, it removes the firebase template from dist before anything else can happen.

@peterp offered help with testing :) I'd say the time has come :) ( or we... test on prod.... hush hush.... x) )

Hmmmm...that's very strange...I don't see why it would be treated any different than any other template we have, other than the fact that the filename has 4 parts instead of 3...

I don't see either. For the sake of it I tried removing '.auth' to keep 'firebase.js.template' --> changed zits, it still gets removed while using the generate command.. Can you try it on your side?

@noire-munich The generator worked for me!

One thing I noticed is the indentation is off in the code that's added to web/src/index.js, everything is indented one level too deep. I think this is because of the init string in the provider, it needs to be something like this:

export const config = {
  imports: [
    `import * as firebase from 'firebase/app'`,
    `import 'firebase/auth'`,
  ],
  init: `const config = {
  apiKey: process.env.FIREBASE_API_KEY,
  authDomain: process.env.FIREBASE_AUTH_DOMAIN,
  databaseURL: process.env.FIREBASE_DATABASE_URL,
  projectId: process.env.FIREBASE_PROJECT_ID,
  storageBucket: process.env.FIREBASE_STORAGE_BUCKET,
  messagingSenderId: process.env.FIREBASE_MESSAGING_SENDER_ID,
  appId: process.env.FIREBASE_APP_ID,
}

const firebaseClient = ((config) => {
  firebase.initializeApp(config)
  return firebase
})(config)`,
  authProvider: { client: 'firebaseClient', type: 'firebase' },
}

Which looks ugly here, but it generates the code correctly!

Also can you rename the config variable that's storing the firebase options? That name is a little too generic I think, this index.js could end up with more config one day and we should be explicit. firebaseConfig perhaps?

@cannikin hooray!
Ok I changed the formatting ( that's something that always bugged me when working on generators, but I understand :) ), I also renamed the variable to be a bit more specific than you suggested.
The reason is, future work for firebase might need a bit more configuration, some that could not be used to init the client.
Have you thought about how we will handle allowing for different signin methods for the same auth? I'm assuming so far we would try to do it on config, but maybe it'll be strategy based - or else.
Anyway, glad it works :), I've pushed the requested changes.