Should very_good_cli be global when we also recommend fvm? It breaks in two ways

[brianegan]

tl;dr Human written: I ran into a conflict with the fvm version of flutter on my project and my global installed version of flutter when running very_good test. Below is a more detailed description of what went wrong combined with some questions about how very_good_cli should work with global vs per-project installations using FVM.

It's kind of an interesting scenario because the app we're working on generates a mason brick, which doesn't include it's own fvm config as it's code meant to end up in our client's repository.

Therefore, fvm * works fine on OUR code to generate the mason brick, but testing the mason bricks output defaulted to global flutter.

---

We tell people to install very_good_cli globally and to pin SDKs per project with fvm. Those two collide. I hit two concrete failures in an fvm-pinned pub workspace (very_good_cli 1.3.0), and I want to figure out where we land.

1. very_good won't run under the project's pinned SDK

The global wrapper is stamped to the SDK that activated it and runs that snapshot with whatever dart is on PATH:

# This file was created by pub v3.12.0.
dart ".../very_good.dart-3.12.0.snapshot" "$@"

Same command, two SDKs on PATH:

# mise Flutter stable, Dart 3.12.0 (what activated it)
$ very_good --version
1.3.0

# fvm's pinned Dart 3.12.1 (what the project uses)
$ very_good --version
Can't load Kernel binary: Invalid SDK hash.

So it works with my system SDK and hard-fails inside the fvm project, which is the one place I actually want to run very_good test. There's a 253-exit self-heal that recompiles, but the error surfaces first and disrupts the run. Reactivating under fvm even dropped a second snapshot right next to the first, but the wrapper stayed pinned to the old one and still picks it.

I know this is mostly a pub-global limitation and not really ours. Raising it for guidance more than as a bug.

2. very_good test runs flutter test on a pure-Dart package

The runner choice is isFlutterInstalled true means flutter test. fvm is Flutter, so Flutter is always "installed", and very_good test picks the wrong runner on a pure-Dart package:

$ very_good test --coverage --min-coverage 100 --no-optimization
Running "flutter test" in . ...
Error: cannot run without a dependency on either "package:flutter_test" or "package:test". Ensure the following lines are present in your pubspec.yaml:

dev_dependencies:
  flutter_test:
    sdk: flutter

PathNotFoundException: Cannot open file, path = './coverage/lcov.info' ...

It only works when Flutter isn't on PATH (falls through to dart test) or with very_good dart test. My CI is green purely because the setup-dart runner has no Flutter. Add Flutter to that runner and the same command breaks with zero code change. Correctness ends up depending on the runner's toolchain instead of the package.

What I want to figure out

• Should very_good test pick flutter vs dart from the pubspec (flutter dep or sdk: flutter) instead of "is Flutter installed"? Keep very_good dart test / very_good flutter test as explicit overrides.
• What's the blessed way to run the project subcommands under a pinned SDK: fvm dart pub global run very_good_cli:very_good, or very_good as a dev_dependency via fvm dart run? If we have a preference, let's document it next to our fvm guidance.
• Anyone else hitting the Invalid SDK hash thrash across multiple fvm projects?

Scaffolding (very_good create) is fine to keep global. This is only about the subcommands that operate on a project under fvm.