feat: support fvm

[eseidel]

Some users don't install Flutter directly, rather they use fvm. So flutter isn't even on their path, just fvm is and they might then use a shell alias to map flutter in the shell to fvm flutter.

One such user noted that this setup does not work with shorebird and is asking for potential fixes to shorebird to auto-detect/support fvm, and/or at least docs on how they're supposed to work together: https://github.com/shorebirdtech/shorebird/issues/472#issuecomment-1754490057

[martin-bertele]

in fact, this morning it works, I've only had ✗ Flutter install is correct (0.8s) [!] The version of Flutter that Shorebird includes and the Flutter on your path are different. Shorebird Flutter: 3.13.6 System Flutter: 3.10.5 and could fix this with https://docs.shorebird.dev/flutter-version#supported-flutter-versions setting shorebird version to 3.10.5

Maybe it was the system restart, even though my reloads/ sourcing the .zshrc should have done the job as well. Congrats, shorebird plays together with fvm for me !

Previously I've used only my f alias, now I've added the flutter alias.

alias f="fvm flutter"
alias flutter="fvm flutter"

and of course then in the executing directory I've got the .fvm folder.

Some hints to fvm would be nice in docu indeed :) Thanks !

[martin-bertele]

had sth similar when switching fvm flutter versions and updating shorebird.

With having the above aliases, after setting shorebird&fvm flutter to same version, VS Code close & restart did the trick (Developer Reload Window not sufficient).

[eseidel]

A user just asked on discord for:

Behavior should probably take this preference order:
If --flutter-version flag is passed, this gets the highest preference.
If flag not found and .fvmrc is found, use it.
If flag not found and .fvmrc is not found, use the latest flutter stable version.

[eseidel]

fvmrc doesn't look difficult to parse (it's just json): https://fvm.app/documentation/getting-started/configuration

I think the only question in my mind is if this should be a wrapper around shorebird, or built into shorebird.

And if it's built into shorebird, should we be detecting fvmrc by default, or only when a flag is passed?

[martin-bertele]

I vote for detect by default and possibly opt out via flag

With so many different flutter projects I wonder how is it possible to survive without flutter per project versioning :)

[josh-burton]

Out of the box support for fvm would be great. Better than opt-in as it ticks the 'it just works' box.

[eseidel]

We'd welcome patches for this, but this isn't on our near-term roadmap without more requests. It doesn't seem to be blocking anyone (but definitely something we could do better).

shorebird release --flutter-version is the way to set the Flutter version currently. Would be neat to read that version either from the current flutter on path, a .fvm file or some fvm command.

[vlazdra]

Hey @eseidel, i just came across an issue with the shorebird_code_push package and the supported Flutter version together with the need to run the Shorebird CLI command via FVM instead of directly with the installed flutter version on my machine.

My FVM was using 3.24.5 and my locally installed flutter version was 3.24.4. I've updated my local installation of Flutter for now. Would be nice if we can specify to the CLI that the FVM should be used via a flag or something.

[felangel]

The main concern I have about supporting FVM is where do we draw the line? There are other Flutter version management tools like Puro and I worry that as soon as we support one it's totally fair for customers to ask us to support any/all others. Long term, I think Shorebird should be your Flutter version manager so I'd personally rather move in that direction but would love to hear what others think.

I'd also love to understand how and why folks are using tools like fvm. For example, are you using it to easily cache/switch global flutter versions or are you using it at the project level exclusively?

[vlazdra]

Hey @felangel 👋

In my personal usage I use FVM to have different Flutter version per release, so that when I go back to a release and need to do a bugfix release I don't need to think about having breaking changes on that branch if flutter updated in the meantime.

Suggestion, not sure if it's viable for Shorebird, would something like Patrol is doing be possible for Shorebird as well? They are providing a flag through their CLI where I can specify the Flutter command:

patrol run --flutter-command=<fvm flutter> Command to use to run the Flutter CLI. Alternatively set the PATROL_FLUTTER_COMMAND environment variable.

Might something like this be possible for Shorebird? shorebird build --flutter-command=fvm flutter

Then specifying the run binaries is left for the user to assign and you don't need to support multiple version control systems as you mentioned.

[eseidel]

We've not spoken with @wojtczakmat about integrating with Patrol yet, but happy to have that conversation.

[vlazdra]

Hey @eseidel 👋

Apologies if my response was confusing.

I didn't mean integrating with patrol, I meant using a similar approach of specifying the flutter command through the CLI like patrol is doing. As per the example above.

That way, you don't need to support flutter version control systems one by one, but rather just receive a command that should be the flutter command and execute that.

Hope I managed to explain it a bit further. 😊

[eseidel]

Ah, that can't work though. Since we don't require a flutter to execute, we provide flutter. So we can't accept a different flutter to use, only a flutter version (which we then fetch our own forked copy of). Hence how shorebird takes a --flutter-version argument and downloads its own copy of flutter (a bit like how fvm does).

[eseidel]

I've posted a proposal on https://github.com/shorebirdtech/shorebird/pull/3238.

It adds a shorebird release --flutter-version=fvm behavior, that will automatically use fvm flutter to determine the version of Flutter to use when building the release. I've also added a similar shorebird release --flutter-version=system to use flutter --version on the path to determine which flutter version to use (instead of defaulting to the latest stable as our current behavior uses).

Does that address the concern of this bug? Please react with 👍 or 👎 to let us know. If it does not address your concern, please explain what support you would like from Shorebird re: FVM. Thanks!

[wesleytoshio]

Suggestion: Support setting flutter_version via shorebird.yaml

Thanks for the clarification!

Wouldn't it be more convenient to allow specifying the Flutter version directly in the shorebird.yaml file?
Something like:

flutter_version: fvm

This way, developers using FVM (or possibly other tools in the future) wouldn't need to remember to add the --flutter-version flag manually during every release.

As projects grow, commands tend to get longer and harder to read. Having this configuration in the YAML keeps things cleaner and helps avoid repetitive flags. Plus, it makes the setup more flexible in case new version managers emerge in the future.

Just an idea for future consideration — thanks again for the great tool!

[IvanDeluxe]

A build failed @ codemagic because of the default flag:

--flutter-version fvm

Here's the logs:

== Building for Android ==

> /Users/builder/.shorebird/bin/shorebird release android --flutter-version '<class '"'"'utils.dict_to_object.new'"'"'>'


Build failed :|
Failed to build for Android

It's been fixed by setting a specific version instead of "fvm" -- thanks :)

[eseidel]

See also https://github.com/shorebirdtech/shorebird/pull/3266.