Description
The road to AngularFire v6
Angular 9 is coming soon! Let's kick off discussions on what AngularFire v6 will look like. We've managed to keep the API stable and introduce no (intentional) breaks for over a year! 🎉
Hope everyone has enjoyed this consistency.
Why break at all?
We currently support three Angular (6, 7, and 8) and Firebase majors (5, 6, and 7) with the current version of AngularFire... that's a lot of work.
To support older versions of Firebase we have a number of conditionals and a lot of unneeded code/types.
To maintain support for older versions of Angular, we've been holding back our typescript version and not adopting any new APIs.
Plan of action
Version 5.3:
Release it, WIP here #2187
Version 5.4:
Reimplement @angular/fire/database-deprecated
using @angular/fire/database
under the hood. It's been raised that database-deprecated
has been pretty broken since we've dropped it from our test suite but it is holding back some of our developers from upgrading. We should try to get them on the latest version of 5, before we start breaking things.
Perhaps at this point we'll mark peer support for Angular 9.0 final. So far in my testing the release candidates seem to work fine and we shouldn't need to break a major to support.
Once we've dealt with that:
Version 5.3.1:
Cherry-pick the fixes for the ng add
and ng deploy
commands.
Version 6:
- Bump the peer dependency to the latest minor of Firebase (currently v7.6)
- Bump the peer dependency of Angular to v9
- Bump the peer dependency of Typescript to bring inline with Angular v9 (currently v3.6)
- Various bugs / types / export naming (see
SEMVER
comments in the source) - Change our build process to use
ng-packagr
WIP Refactor build process #2117 - Drop the
angularfire2
shim releases on NPM - Add the SDK proxy that
AngularFireAnalytics
andAngularFireRemoteConfig
use in the upcoming 5.3 release (Adding AngularFireAnalytics, AngularFireRemoteConfig, and refactoring DI Tokens #2187) to all the modules and drop the instance getters. Make all modules side-effect free (no longer importing the SDKs)
Version 6.1:
- "Lazy" versions of all the "non-lazy" modules. These do not assume the developer has loaded any of the Firebase SDKs and will dynamically import them; obviously some APIs will be different.
Version 7:
- Drop the "non-lazy" modules
- Move all our operators, observables, etc. to pure-functions (more on this soon)
- whatever else we think of by then...
Things we're thinking of:
- Reduce the amount of code in this library by leaning on RxFire
Can we build a migrator forDuring my investigation I found little evidence that those still using@angular/fire/database-deprecated
in a reasonable timespan? If so, I'll dropdatabase-depreciated
in version 6, if not we'll punt until version 7.database-depreciated
had moved to 5.0 stable; I've decided to drop for 6.0.- How different would the "lazy" modules actually be? Can we just migrate over to them in 6 rather than have them be optional until 7?
Require the userngcc no longer has issue with thisimport 'firebase/*'
themselves before use of the non-lazy modules, this would allow us to export all the packages under@angular/fire
and mark them as having no side-effects.- Shallow up the exports, if we're entirely side-effect free we can export everything in
@angular/fire
rather than having sub-packages. - Strong type support in the vanilla Firestore SDK is available now with FirestoreDataConverter. Can we leverage this to get some of our Firestore type work for free in AngularFire & make the guarantees "stronger"? Can we use this for production-worthy state-transfer?