René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Discussion: the road to AngularFire v6","articleBody":"# The road to AngularFire v6\r\n\r\nAngular 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! 🎉\r\n\r\nHope everyone has enjoyed this consistency.\r\n\r\n## Why break at all?\r\n\r\nWe 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.\r\n\r\nTo support older versions of Firebase we have a number of conditionals and a lot of unneeded code/types.\r\n\r\nTo maintain support for older versions of Angular, we've been holding back our typescript version and not adopting any new APIs.\r\n\r\n## Plan of action\r\n\r\n### Version 5.3:\r\n\r\nRelease it, WIP here #2187 \r\n\r\n\u003cstrike\u003e\r\n\u003ch3\u003eVersion 5.4:\u003c/h3\u003e\r\n\r\nReimplement `@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.\r\n\r\nPerhaps 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.\r\n\r\nOnce we've dealt with that:\r\n\u003c/strike\u003e\r\n\r\n### Version 5.3.1:\r\n\r\nCherry-pick the fixes for the `ng add` and `ng deploy` commands.\r\n\r\n### Version 6:\r\n\r\n* Bump the peer dependency to the latest minor of Firebase (currently v7.6)\r\n* Bump the peer dependency of Angular to v9\r\n* Bump the peer dependency of Typescript to bring inline with Angular v9 (currently v3.6)\r\n* Various bugs / types / export naming (see `SEMVER` comments in the source)\r\n* Change our build process to use `ng-packagr` #2117 \r\n* Drop the `angularfire2` shim releases on NPM\r\n* Add the SDK proxy that `AngularFireAnalytics` and `AngularFireRemoteConfig` use in the upcoming 5.3 release (#2187) to all the modules and drop the instance getters.\r\n* ~Make all modules side-effect free (no longer importing the SDKs)~\r\n\r\n### Version 6.1:\r\n\r\n* \"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.\r\n\r\n### Version 7:\r\n\r\n* Drop the \"non-lazy\" modules\r\n* Move all our operators, observables, etc. to pure-functions (**more on this soon**)\r\n* whatever else we think of by then...\r\n\r\n### Things we're thinking of:\r\n\r\n* Reduce the amount of code in this library by leaning on RxFire\r\n* \u003cstrike\u003eCan we build a migrator for `@angular/fire/database-deprecated` in a reasonable timespan? If so, I'll drop `database-depreciated` in version 6, if not we'll punt until version 7.\u003c/strike\u003e During my investigation I found little evidence that those still using `database-depreciated` had moved to 5.0 stable; I've decided to drop for 6.0.\r\n* 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?\r\n* ~Require the user `import '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.~ ngcc no longer has issue with this\r\n* Shallow up the exports, if we're entirely side-effect free we can export everything in `@angular/fire` rather than having sub-packages.\r\n* Strong type support in the vanilla Firestore SDK is available now with [FirestoreDataConverter](https://firebase.google.com/docs/reference/js/firebase.firestore.FirestoreDataConverter.html). Can we leverage this to get some of our Firestore type work for free in AngularFire \u0026 make the guarantees \"stronger\"? Can we use this for production-worthy state-transfer?","author":{"url":"https://github.com/jamesdaniels","@type":"Person","name":"jamesdaniels"},"datePublished":"2019-12-17T19:20:35.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":38},"url":"https://github.com/2267/angularfire/issues/2267"}