firebase_core
| Package | Kind | Provides the role | Needs | Choose with |
|---|---|---|---|---|
smf_firebase_core | infrastructure | none | nothing | -m firebase_core |
firebase_core sets up Firebase with firebase_core, which the other Firebase packages of an app build on. firebase_crashlytics, firebase_analytics, firebase_messaging and firebase_auth depend on it, so it comes with them.
What it adds to the app
The module adds firebase_core: ^4.15.0 to the dependencies, and these files:
| In the app | What it is |
|---|---|
lib/firebase_options_dev.dart, lib/firebase_options_staging.dart, lib/firebase_options_prod.dart | The options of each flavor. Until a flavor is configured, its file is a placeholder in the form that flutterfire_cli writes. Each platform throws an UnsupportedError that gives the command, so the app compiles but a build of that flavor stops at start-up. |
lib/firebase_options_of_flavor.dart | firebaseOptionsOfFlavor, which picks the options by appFlavor. A release build keeps only the options of its own flavor. |
tool/configure_firebase.dart | The script that configures one flavor |
In the platform phase of bootstrap(), before the services of the app, it initializes Firebase:
await Firebase.initializeApp(options: firebaseOptionsOfFlavor);
It also asks for iOS 15.0 or newer, the lowest version that the Firebase SDKs support, which the app has already. It adds a section on Firebase to the README of the app, which tells how to configure a flavor, such as for another Firebase project or on another machine.
The guide for coding agents of the app gets a section "Firebase" too. It says that the options of a flavor are a placeholder until tool/configure_firebase.dart writes them, that an agent runs that script only when asked and does not run flutterfire configure, and that a test which runs main() or bootstrap() starts Firebase.
The machine
Before generation, the module checks what the FlutterFire CLI needs: the Firebase CLI, a login of the Firebase CLI that Google still accepts, flutterfire_cli 1.4.1 or a later 1.x activated globally, and on macOS the Ruby gem xcodeproj 1.23.0 or newer. On other systems it warns that the Xcode project has to be set up on a Mac. A missing tool is a warning with instructions. In a terminal, SMF offers to install the Firebase CLI, to log in (or to log in again when the login has expired) and to activate flutterfire_cli, and asks before each. See Firebase.
For the modules that depend on it, the package has one more check, FirebaseCliVersionCheck. A module whose command exists only in newer versions of the Firebase CLI puts it among its own checks of the machine, with the lowest version that has the command, as firebase_auth does with 15.34.0. The check reads firebase --version and tells how to update an older Firebase CLI, which SMF does not update itself. On a machine without the Firebase CLI, the check of firebase_core runs first and offers the installation, and the check of the version then reads the version that was installed. See a check from the module you depend on.
After generation
Once the app has its packages, the module configures the flavor dev in it with the terminal, after asking:
dart tool/configure_firebase.dart dev
The FlutterFire CLI asks for the Firebase project and writes the options of the flavor. On macOS the script runs flutterfire once for each Xcode build configuration of the flavor, and once elsewhere. Then it formats the options and runs each Dart file of tool/firebase_configured/, in the order of their names.
The module publishes the id of this step as FirebaseCoreModule.configureStep, so that the modules that depend on it can continue the step with steps of their own. firebase_auth continues it with the script that enables the sign-in methods in the project that you chose, which runs right after it succeeds. A module that has to follow every run of flutterfire, for every flavor, puts a file into tool/firebase_configured/ instead, as firebase_crashlytics does.
A run without a terminal, a run that skips external setup, and a run that lacks what the script needs print the command to run later instead, followed by the commands of the steps that continue it.
Configure the other flavors with the same script, each for a project of its own or for one that they share, and commit what it writes:
dart tool/configure_firebase.dart staging --project=<id>
See One project for each flavor, which also lists what repeats for each project.
Choosing it
smf create asks which infrastructure modules the app has, and offers this one. It also comes with the other Firebase modules. To choose it without the question:
smf create my_app -m firebase_core