Angularfire: [Discussion] Drop the 2 from AngularFire2

[jsayol]

Context: Igor Minar's keynote speech at NG-BE Conf (link to relevant part)

The official guidelines seem to be to refer to angular simply as "Angular", without any version number attached to it. Considering Angular 4 will come out in less than 3 months, then Angular 5 a few months later, then Angular 6 etc, it might be confusing having to keep using AngularFire2.

I understand simply dropping the 2 might not be possible due to AngularFire for Angular 1.x but I think it's important to address how to best tackle this while AF2 is still in beta, before moving to RC or stable.

Starting with Angular 4, one possible solution would be to merge it all in one single package ("angularfire") maintaining separate versions for each. As in, keep all current versions of AF1 and AF2 in that one package and then simply publish a new 4.0.0 version with the current AngularFire2 codebase. There might be some version number collisions between AF1 and AF2 right now, though - AF1 is currently at 2.1.0 and AF2 is at 2.0.0-beta.6.

Ideas?

[jsayol]

Actually, merging the two packages might not be a good idea. Simply creating a new 4.0.0 version on the "angularfire" package with the most recent AF2 code seems like the best option to me. You would still keep the "angularfire2" package for any project currently using it, of course.

[katowulf]

Merging the two packages won't be practical. Semantically, they could reside in the same GitHub repo, but they would still be an entirely different API, code base, documentation set, and testing infrastructure. About the only similarities are the names and the Travis integrations.

Keeping them separated is probably the simplest way to avoid a lot of confusion and frustration trying to apply documentation, code samples, Stack Overflow answers, et al to these libraries. In fact, a more divergent namespace would probably make all of this much clearer and easier to differentiate.

@jwngr @abehaskins @davideast to disagree or add flavor.

[katowulf]

@jsayol thanks for initiating the discussion.

[jsayol]

Keeping them separated is probably the simplest way to avoid a lot of confusion and frustration trying to apply documentation, code samples, Stack Overflow answers, et al to these libraries.

Yeah, that's a good point.

I don't really see an easy solution to this. Maybe keeping it as AngularFire2 might be best, I don't know.

[jsayol]

Just adding this: https://twitter.com/IgorMinar/status/808401117822357504

[jwngr]

Our primary goal should be to avoid confusion for end-users. Our secondary goal should be to make our lives as the library publishers easier.

Staying in lock step with Angular's version number is a fool's errand and seriously impairs our secondary goal (proof of that is that we already have AngularFire(1) version 2.x.x so we couldn't even do this if we wanted). It does make our primary goal easier though. I wish we could just call it something else since Angular2 is such a different beast and there will be little to no clear upgrade path from AngularFire(1) to AngularFire2. Towards that end, we could move to call this something entirely new like ngfire and just say that angularfire is for Angular(1) and ngfire is for Angular2+.

I'm not in love with any of the naming options really. I think it's going to be confusing for end users no matter what we do.

[jsayol]

Staying in lock step with Angular's version number is a fool's errand

Definitely. I just realized that by suggesting to jump to 4.0.0 it might have looked like that's what I was proposing to do. It's not.

I like the idea of rebranding the library altogether. It sets a very clear boundary between AngularJS (1.x) and Angular (2+). For end-users, the transition from angularfire2 to the new package would be relatively painless: change the dependency in package.json and replace any import statements, which should be a matter of seconds in most IDEs. At first it might cause a bit of confusion to some users but in the long run it seems like the better option.

Sticking with angularfire2 might be the easiest option right now but I think it'll become increasingly more confusing as time passes and Angular starts hitting higher version numbers.

For what it's worth , both ngfire and ng-fire are available as npm package names.

[WhatsThatItsPat]

How about firebang?

---

This works on many levels:

• Fire+Bang is fun unto itself. It sounds like kids playing cops & robbers.
• Fireb+Ang is obviously a combination of Firebase + Angular.
• Fireba+NG sneaks in the prefix / abbreviation / namespace.
• Firebase & Firebang have 8 letters apiece. There's something to be said for balance.
• FireAngular would be a simple swap and a nod to what is there now. But that doesn't roll off the tongue. FireBangular perhaps has a better ring to it, but is slightly absurd. Firebang is a nice compromise.

[WhatsThatItsPat]

If you want to go the risque route, how about fng?

Pronounced eff-ing, of course.

[jsayol]

Adding this discussion on twitter started by @ocombe since it feels relevant: https://twitter.com/toddmotto/status/809912496454766593

I linked to @toddmotto's tweet since it has some interesting replies but click around for the whole conversation.

Maybe for now it'd be best to wait and let things settle.

Does the Angular team have an official position when it comes to naming libraries? Maybe this discussion should be happening at that level since I'm sure many other Angular-related projects will be facing this very same issue.

[ocombe]

The Angular team official position is: don't use ng2-, but you can use ng- for the name of your library, just don't use ng- for the directives because it's the "official" namespace (ngIf, ngFor, ...). Which means that ng- doesn't seem like a good prefix for the library name in my opinion.
That's why I think that ngx- is nice :)

[Splaktar]

Is there something prohibiting the name from being @angular/firebase in NPM and angular/firebase in GitHub?

[jsayol]

That seems like a good option. Maybe @angular/fire and angular/fire to better differentiate it from the official firebase package and repo.

This also gives it a name that's really close to the current one, which is a plus.

[Splaktar]

From Twitter, it looks like AngularFire2 was going to be moving under the Firebase organization at Google. So this would mean that it would need to be @firebase/angular but also raised on Twitter was that this name looks like a fork of @angular/angular. @firebase/angularfire will continue to be the Angular 1.x version, so that's not an option either.

More broken projects/breaking changes coming as part of this too :(

[ocombe]

you could name it JustAngularFire :D

[jsayol]

@firebase/angularfire will continue to be the Angular 1.x version, so that's not an option either

Actually @firebase/angularfire is available on NPM, but on github firebase/angularfire is indeed the repo for v1 so that could certainly cause some confusion.

Maybe @jwngr's initial proposal of ngfire might be the best bet placing it under the Firebase org: @firebase/ngfire on NPM and firebase/ngfire on github.

[Toxicable]

Just like to add my 2 cents here, I like the sounds of the @ namespace, so weather it's being moved under the firebase organisation then I think @firebase/angularfire would be suited but otherwise @angular/fire or @angular/angularfire would both work well

[wbhob]

@angular/firebase?

[M-a-c]

@wbhob Totally agree.
@angular/firebase would make the most sense like @angular/material2 (they still put a 2 for some reason..)
or @angular/cli
its really how the eco system /should look

[vinagreti]

I agree with @wbhob but I see a problem that we will end up with two packages with same name firebase and @angular/firebase and it can be confused. Is there any plan to remove the need for firebase package and make angularfire2 standalone or it will be always needed?
Also, firebase is used to handle the storage, so, for the current version (beta.8), we can't use only angularfire2.
I suggest we remove the need for firebase from our apps and make the angularfire2 handle the storage and have firebase in its package.json so the users will not know that they are using furebase package, and won't be any confusion. So, we can move to @angular/firebase without any confusion.

[wbhob]

It won't cause any confusion because people will only get @angular/firebase if they are angular users. It is a completely different package. To install it, someone would have to directly install and reference the package as @angular/firebase.

Wilson Hobbs
CEO/Founder/Developer at Canal
11th Grade at The Lovett School

Personal Information
E-mail: [email protected]
Cell: [phone]
Website: www.wilsonhobbs.com (https://www.wilsonhobbs.com)
Twitter/Instagram/Facebook: @wbhob

Canal Information
E-mail: [email protected]
Web: www.getcanal.com (https://www.getcanal.com/)

Twitter/Instagram/Facebook: @getcanal

On Apr 5, 2017, 9:09 AM -0400, Bruno da Silva joão [e-mail], wrote:
>

I agree with @wbhob (https://github.com/wbhob) but I see a problem that we will end up with two packages with same name firebase and @angular/firebase and it can be confused. Is there any plan to remove the need for firebase package and make angularfire2 standalone or it will be always needed?
Also, firebase is used to handle the storage, so, for the current version (beta.8), we can't use only angularfire2.
I suggest we remove the need for firebase from our apps and make the angularfire2 handle the storage and have firebase in its package.json so the users will not know that they are using furebase package, and won't be any confusion. So, we can move to @angular/firebase without any confusion.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub (https://github.com/angular/angularfire2/issues/716#issuecomment-291855874), or mute the thread (https://github.com/notifications/unsubscribe-auth/AEPIEl_UcilcYzjfOkeQFEOdaqwFGsWBks5rs5KHgaJpZM4LJoS4).

[vinagreti]

But what about the class names? Would it be AngularFire, AngularFirebase, firebase, Firebase?
Will the package be named @angular/firebase but the class named AngularFire? That is confuse to me...
I think the class name should refer to its package name. If a new user knows only the @angular/firebase package name, they will assume the class name should be something like FirebaseModule and not AngularFireModule.
Also, for packages like @angular/* they use the * as the class name and not prefix the class with Angular like AngularFirebaseModule. So it won't be the same as using others angular packages.
Finally, in version beta.8 we need both packages to use database and storage, angularfire2 and firebase, so the user still need to install both and that is the confusion point between firebase and @angular/firebase.

[Splaktar]

Based on feedback from David East, it can't be under the @angular/ name space. It needs to go under @firebase/ at some point.

There are no plans that I have heard to remove the dependency on the firebase package. It does a lot more for AngularFire2 developers than just Storage. Many apps are already built using both libraries together. I don't expect that to change.

[davideast]

We have a plan for this. Closing for now. I think you'll all like it.