feat: add option to define flutter sdk path or use fvm

[mugbug]

Description

For projects that use fvm it'd be pretty handy to be able to make very_good commands to also respect the version defined on .fvm/fvm_config.json instead of always using the global sdk one.

Proposal

Commands that should support this option

• All those that use flutter

API definition

Option A: --use-fvm

very_good test --use-fvm

• Pro: Simplicity
• Con: Only works with fvm

Option B: --path=./flutter/sdk/path

very_good test --path=./.fvm/flutter_sdk

• Pro: Completely customizable
• Con: Error prone and more complex to use

As a suggestion, I think we could go with both since it doesn't seem too much work. Any thoughts?

[DFelten]

It would be great to be able to use FVM for running tests via very_good. We work on many projects with different Flutter versions and it is relatively inconvenient to always adjust the global Flutter version first. In the CI this is also not always possible.

[mugbug]

@felangel @erickzanardo @renancaraujo Any thoughts on this? Looking forward on working on a PR for this within this week

[erickzanardo]

@felangel @erickzanardo @renancaraujo Any thoughts on this? Looking forward on working on a PR for this within this week

One concern that I have about that is with breaking changes on the flutter CLI.

Imagine that an option from the cli is removed or changed on a new flutter version, we would need to change the CLI to conform with that change.

But with the use of fvm, users could specify that older version that the CLI don't support anymore and an error would happen.

One way to mitigate that is to implement a way inside the cli to check if the flutter version current in use is supported by the current CLI, but I wonder how complicated that would be.

[mugbug]

@erickzanardo Thanks for the reply!

If I got that right, I think this problem would occur either if we support fvm or not, wouldn't it? I understand that if we want to keep supporting lower Flutter CLI versions (in case of breaking changes), we'd already need to implement some sort of check even without supporting fvm.

But indeed we could have a problem if fvm publishes some new version with breaking changes, which will require us to support it and publish a very_good_cli version with breaking changes or add a check to support older and newer fvm versions.

[Thelm76]

+1 It would be great for CI/CD to add this kind of flag. I have an ADS pipeline running where fvm is defined but flutter is not in path, it would help a bit to avoid exporting a new PATH for every execution....

[chillbrodev]

Hello, I ran into a similar issue today with VeryGood CLI and FVM.

As we know, FVM lets us manage multiple flutter versions, but there seems to be a glitch with the global FVM setting.

I work on multiple Flutter projects and not all of them use the same Flutter version. One of the projects is not on latest Flutter it is locked to 3.7.12.

My global FVM instance was set to 3.13.4 and when I ran very_good packages get -r and it seemed to use the global flutter ... which started resulting in package/build-runner failures since the Global Dart SDK was set higher than the project SDK. Seems like the global flutter was being used instead of my local project flutter.

FVM stores a local copy of the Flutter SDK to the project directory.

It would be great to be able to specify where very_good should look for the Flutter Path.

[supposedlysam-bb]

Do any of you run into the issue where running very_good test --coverage gives you an error because it's trying to execute the tests inside of your fvm flutter directory? If so, have you figured out a workaround?

[alestiago]

@supposedlysam-bb I don't actively use FVM, but I think FVM 3 might help to solve this issue. Have you tried it? Does it solve this issue for you?

[supposedlysam-bb]

@alestiago FVM 3.0 seems to still be in beta. I'll probably just wait until it gets moved to stable. Thanks for your response though!

[tomarra]

Thanks all for the discussion on this topic. We're going to hold on any further updates on this until we see FVM 3.0 get released as we think this fixes the issue.

[smtp10185]

fvm 3.0 now released! https://github.com/leoafarias/fvm/blob/main/CHANGELOG.md

[supposedlysam-bb]

I ended up downloading v3.0.10 today and had to do the following to get it to work. Not sure if this is available in previous versions or not, but this worked for me.

• brew install or pub activate the latest version of FVM
• run fvm config --cache-path '~/development/.fvm to move the flutter_sdk into a different directory outside of my project
• run fvm use for it to create the .fvmrc file and perform any migrations
• run very_good test --coverage and all tests passed without errors

Just upgrading to FVM version 3.0 did not work, but setting the cache location allowed the .fvm/flutter_sdk to become a symlink and become ignored when running the cli.