feat: make the cli compatible with jaspr projects by schultek · Pull Request #440 · invertase/flutterfire_cli

schultek · 2026-04-20T12:17:59Z

Description

Resolves #421

This makes the Cli not throw the FlutterAppRequiredException exception when run in a Jaspr project, since Jaspr has support for running Flutter plugins such as the Firebase plugins.

CC @abdallahshaban557 as discussed

Type of Change

✨ feat -- New feature (non-breaking change which adds functionality)
🛠️ fix -- Bug fix (non-breaking change which fixes an issue)
❌ ! -- Breaking change (fix or feature that would cause existing functionality to change)
🧹 refactor -- Code refactor
✅ ci -- Build configuration change
📝 docs -- Documentation
🗑️ chore -- Chore

gemini-code-assist

Code Review

This pull request introduces the isFlutterCompatiblePackage property to the Package class, enabling packages that depend on 'jaspr' to be recognized as Flutter-compatible. The isFlutterApp logic was updated to include these compatible packages, and new unit tests were added to verify the classification of various package types. I have no feedback to provide.

russellwheatley · 2026-04-23T11:25:19Z

I don’t think this PR is the right solution, even though it fixes the immediate Jaspr case.

The core issue is that it changes the definition of “Flutter app” globally by treating any package with a jaspr dependency as app-compatible in package.dart. That is too specific to one framework, and it means every future non-Flutter host would need another hardcoded special case here. More importantly, isFlutterApp is the predicate that unlocks the rest of the CLI surface, not just configure (package.dart, base.dart).

That has broader effects than the PR description suggests:

configure is explicitly described as “Configure Firebase for your Flutter app” in config.dart. It does more than generate Dart options: it also validates native inputs, fetches platform configs, writes Android/iOS/macOS files, and writes firebase.json state for later replay (config.dart, config.dart, config.dart, config.dart).
reconfigure is also affected because it uses the same gate and then assumes the current project owns host app state in firebase.json and can replay native integration from it (reconfigure.dart, reconfigure.dart, reconfigure.dart).
update is affected as well; once this gate is relaxed it will run flutter clean, flutter pub upgrade, and flutter pub get for projects that may not actually be Flutter apps (update.dart).
install is also behind the same gate, even though it is more package-friendly and mostly just does dart pub add/remove (install.dart).
So the concern is not just “Jaspr support”; it is that this PR widens the meaning of “app” for every command that currently assumes app ownership of native config and reconfigure state.

I think a better direction would be to keep flutterfire configure as the host-app integration command and introduce a separate command, something like flutterfire configure-runtime, for projects/packages that need runtime config generation without being treated as host apps.

That alternative could focus on dart specific integration (e.g. firebase_options.dart), as far as I can tell, most of the CLI flags in configure command wouldn't be needed by Jaspr or presumably similar platforms.

There is already common code in the current configure flow that could be reused for this:

Dart/web/windows/linux Firebase app lookup and config conversion in firebase_dart_options.dart
the shared platform fetch orchestration in firebase_platform_options.dart
the Dart config writer in firebase_dart_configuration_write.dart

That would let us support runtime config generation for package-style or alternate-host projects without redefining them as Flutter apps and without unintentionally enabling reconfigure, update, and other app-specific behavior.

abdallahshaban557 · 2026-04-23T14:39:49Z

hI @russellwheatley - Can you elaborate a bit on how the experience would then be for a Jaspr developer using the CLI with this recommended approach?

russellwheatley · 2026-04-23T16:01:17Z

Hey @abdallahshaban557 - the diff would be:

flutterfire configure-runtime + arguments

rather than:

flutterfire configure + arguments

flutterfire configure-runtime would have only a few arguments as it'd be configuring just dart_options.dart. Something like:

flutterfire configure-runtime path=/path/to/dart_options.dart appId=firebase-web-app-id --overwrite-existing

Could even create an app on their Firebase project and/or create Firebase project like configure command if they wish.

abdallahshaban557 · 2026-04-25T18:57:33Z

Hi @russellwheatley,

I like this direction and it makes sense, I also like that it opens the door for future surfaces we might want to support - which in the long term I definitely want to pursue.

@schultek - got any thoughts on this direction? Can you update this PR accordingly?

schultek · 2026-04-27T08:32:46Z

Thanks @russellwheatley for looking into this.

The proposed changes I made are with the goal to have the least possible change in the package, but I'm open to other approaches.

Maybe instead of adding a separate command, we can abstract an App class with FlutterApp and JasprApp implementations that can guard specific behaviors inside the existing commands (e.g. FlutterApp would enable native targets and flutter cli calls, while JasprApp would have a fixed web target and skip all flutter cli calls)

Then we have more specific control over what things are done for each command without needing separate -runtime variants with duplicate logic, and it would still be "transparent" to the user and just work.

russellwheatley · 2026-05-08T08:16:25Z

@schultek - that could work. I think I'd prefer to call it RuntimeApp or something along those lines rather than specifically targeting Jaspr.

How do you propose to invoke that cli path?
How do you propose to guard against all the arguments that will be superfluous to it (e.g. throw error when invoking redundant arguments)?

schultek · 2026-05-19T11:12:05Z

How do you propose to invoke that cli path?

I would still detect Jaspr as a dependency, like it's done with flutter.

How do you propose to guard against all the arguments that will be superfluous to it (e.g. throw error when invoking redundant arguments)?

I'm not feeling strongly about this, but I'd probably prefer just a warning that a flag will be ignored / isn't supported in that cli path.

…asses

schultek · 2026-05-22T07:16:52Z

@russellwheatley @abdallahshaban557 I've updated the approach, lmk what you think.

abdallahshaban557 · 2026-06-13T20:08:09Z

Hi @russellwheatley - can we please check on this PR next week?

github-actions · 2026-07-11T20:52:53Z

Hello 👋, this PR has been opened for more than 2 months with no activity on it.

If you think this is a mistake please comment and ping a maintainer to get this merged ASAP! Thanks for contributing!

You have 15 days until this gets closed automatically

schultek · 2026-07-27T07:31:39Z

@russellwheatley @abdallahshaban557 Could we get some eyes on this please?

abdallahshaban557 · 2026-07-28T19:24:01Z

Checking with Russell, Kilian. Will get back to you!

russellwheatley

Thanks @schultek. This seems better than the original approach - moving from a single global isFlutterApp flag to an App capability model addresses my earlier concern that widening the flag would unintentionally unlock reconfigure/update/install behavior. Having configure key off flutterApp.android/.ios/.web per-command rather than one blanket boolean seems better to me than a single flag.

A few things inline before this can land, plus one design question on extensibility.

russellwheatley · 2026-07-29T09:19:36Z

+  jaspr: ^0.23.0
+'''),
+      );
+      expect(package1.isFlutterCompatiblePackage, isTrue);


Tests don't compile right now, this is why CI is red on all 3 platforms:

test/unit_test.dart:285:23: Error: The getter 'isFlutterCompatiblePackage' isn't defined for the type 'Package'.

I think this should be isRuntimePackage. Same issue on line 295.

russellwheatley · 2026-07-29T09:19:36Z

+  jaspr: ^0.1.0
+'''),
+      );
+      expect(jasprApp.isFlutterApp, isTrue);


This assertion looks wrong regardless of the naming issue above. jasprApp only depends on jaspr (no flutter/flutter_localizations), so per the current isFlutterApp impl this should be isFalse, with isRuntimeApp being the one that's true.

russellwheatley · 2026-07-29T09:19:36Z

+  void commandRequiresFlutterApp({bool allowRuntimeApp = true}) {
    if (flutterApp == null) {
      throw FlutterAppRequiredException();
    }
+    if (!allowRuntimeApp && flutterApp is FlutterRuntimeApp) {
+      throw FlutterAppRequiredException();
+    }
    _warnUserIfRunningGlobally();


Nothing calls commandRequiresFlutterApp(allowRuntimeApp: false) anywhere in config.dart/reconfigure.dart/update.dart/install.dart. If there's no command that should reject FlutterRuntimeApp, maybe drop this parameter until there is one.

russellwheatley · 2026-07-29T09:19:36Z


+  /// Returns whether this package is a runtime package.
+  ///
+  /// These are packages that are compatible with Flutter plugins, even
+  /// if they don't depend on the Flutter SDK directly.
+  ///
+  /// This is currently only true for packages that depend on Jaspr.
+  late final bool isRuntimePackage = dependencies.contains('jaspr');


I think we should support Jaspr, but this detection is hardcoded to match just that. Supporting a second non-Flutter host later means adding another hardcoded dependency check here plus another subclass in flutter_app.dart.

russellwheatley · 2026-07-29T09:19:36Z

    final package = await Package.load(appDirectory);
-    if (!package.isFlutterApp) {
-      return null;
+    if (package.isFlutterApp) {
+      return FlutterProjectApp(package: package);
    }
-    return FlutterApp(
-      package: package,
+    if (package.isRuntimeApp) {
+      return FlutterRuntimeApp(package: package);
+    }
+    return null;


Since we're introducing "runtime apps" as a first-class concept rather than a Jaspr-only special case, could this be a small registry of adapters instead, something like a list of {detect: (Package) => bool, capabilities: ...} entries that load iterates over, so the next framework is additive rather than another edit here? Doesn't need to be elaborate, just enough that Jaspr isn't the only thing this can ever recognize.

russellwheatley · 2026-07-29T15:44:15Z

As an FYI, I've merged with main to see latest CI run

make the cli compatible with jaspr projects

e8abd80

schultek had a problem deploying to CI Environment April 20, 2026 12:18 — with GitHub Actions Failure

gemini-code-assist Bot reviewed Apr 20, 2026

View reviewed changes

schultek temporarily deployed to CI Environment April 23, 2026 09:39 — with GitHub Actions Inactive

github-actions Bot added the Needs Attention OP created or responded to issue and it needs attention. label Apr 27, 2026

extend FlutterApp into FlutterProjectApp and new FlutterRuntimeApp cl…

767d788

…asses

schultek had a problem deploying to CI Environment May 22, 2026 07:16 — with GitHub Actions Failure

github-actions Bot added the Stale label Jul 11, 2026

github-actions Bot closed this Jul 26, 2026

russellwheatley reopened this Jul 29, 2026

russellwheatley had a problem deploying to CI Environment July 29, 2026 08:15 — with GitHub Actions Failure

github-actions Bot removed the Stale label Jul 29, 2026

russellwheatley requested changes Jul 29, 2026

View reviewed changes

Merge branch 'main' into feat/jaspr-compatibility

573ca6d

russellwheatley had a problem deploying to CI Environment July 29, 2026 15:43 — with GitHub Actions Failure

Uh oh!

Conversation

schultek commented Apr 20, 2026

Description

Type of Change

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

russellwheatley commented Apr 23, 2026

Uh oh!

abdallahshaban557 commented Apr 23, 2026

Uh oh!

russellwheatley commented Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

abdallahshaban557 commented Apr 25, 2026

Uh oh!

schultek commented Apr 27, 2026

Uh oh!

russellwheatley commented May 8, 2026

Uh oh!

schultek commented May 19, 2026

Uh oh!

schultek commented May 22, 2026

Uh oh!

abdallahshaban557 commented Jun 13, 2026

Uh oh!

github-actions Bot commented Jul 11, 2026

Uh oh!

schultek commented Jul 27, 2026

Uh oh!

abdallahshaban557 commented Jul 28, 2026

Uh oh!

russellwheatley left a comment

Choose a reason for hiding this comment

Uh oh!

russellwheatley Jul 29, 2026

Choose a reason for hiding this comment

Uh oh!

russellwheatley Jul 29, 2026

Choose a reason for hiding this comment

Uh oh!

russellwheatley Jul 29, 2026

Choose a reason for hiding this comment

Uh oh!

russellwheatley Jul 29, 2026

Choose a reason for hiding this comment

Uh oh!

russellwheatley Jul 29, 2026

Choose a reason for hiding this comment

Uh oh!

russellwheatley commented Jul 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

russellwheatley commented Apr 23, 2026 •

edited

Loading