feat: make the cli compatible with jaspr projects

[schultek]

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]

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]

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]

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.