RFC: FVM Changes

[leoafarias]

RFC: Locked:
Thank you all for the feedback, we have made considerable improvements for 3.0.0 based on the information provided.

A few takeaways.

• Global command stays; however, if you use global, you should be using FVM executable, not pub global.
• We have simplified the FVM configuration.
• Much better DX, notifications, warnings, and corrective actions.
• Tighter integration with VsCode.

-- Original --

TLDR:

• FVM has come to a critical tool in the Flutter Dev toolbox.
• We should aim to improve compatibility with Flutter tools and recommended workflows where possible.
• Suggestion - Deprecate global command.
• Suggestion - Executables > pub global activate
• Refactor, with the simplified workflows in mind.

---

When I first created FVM, I never imagined that it would have grown in scope and usage to become the go tool for the Flutter version management challenges.

The community has embraced it in a way I did not expect, and it is great to see the number of people mentioning how much easier FVM makes their dev experience and how much it has saved them.

However, even though FVM does an excellent job in most of the cases and it's clear that it's solving a significant problem, it can, in a way, create "noise," where issues are not evident where they could be coming from (FVM, Flutter or Dev Environment).

That is an ongoing challenge when seeing new issues on both FVM and issues that mention the use of FVM within the Flutter repo.

Because FVM has become a more critical part of the Flutter developer toolset, I would like to open up a discussion of some ideas and also gather feedback and suggestions on what I think might be some possible solutions. Also, this discussion will list some essential items and highlight some pain points with Flutter version management.

Principles

While maintaining the project, as it gained popularity, many individual requests have been to extend, enhance or modify some Flutter CLI behaviors. That is why I try to follow these principles.

• Always use Flutter tools when interacting with the SDK.
• Do not override any Flutter CLI commands.
• Follow Flutter suggested installation instructions accomplish caching.
• Should extend Flutter behavior and not modify it.
• API should be simple and easy to understand.

Basic use cases

• Cache multiple Flutter versions (faster switching without download)
• Configure a version per project Reference
• Flutter version routing Reference
• IDE compatibility (vscode, android studio detects linked version)

Challenges

As you can imagine, some challenges exist when supporting a tool like Flutter and the breadth of dev environments (devs love to customize their environments!)

Routing

• The commands need to be proxied fvm flutter {command} to support routing. It passes the command and runs as a separate process. It works surprisingly well but sometimes can be frustrating from a DX perspective with an issue like [Enhancement] No colors or formatting when using fvm flutter proxy #202
• Routing solves the monorepo problem and passes the Flutter SDK that is running the process down into its environment variables for any other sub-process to grab the same version.
• Routing is not "always" needed, and to be honest, I prefer to call the SDK directly when running standard build and run commands; when you have subprocesses, that is when routing comes in handy.

Pub global activate

• One of the most significant pain points with FVM is that most users install with dart pub global activate; because most Dart SDK users are Flutter developers, it means the Dart SDK version is embedded with Flutter SDK, which means a change in the Flutter (PATH) global version would cause a difference in the Dart version, and cause the following issue Running a globally activated binary after SDK upgrade - Can't load Kernel binary: Invalid SDK hash. dart-lang/pub#2593
• You can install FVM as an executable, Brew, Chocolatey, which solves the problem above.

Suggestions

Based on my experience, here are some suggestions for changes that can be made to remove some of the noise added to the Flutter team and simplify FVM in some ways.

• Deprecate FVM global command. I understand the benefit of this command, but maintaining the main version of Flutter through the FVM causes confusion and noise when troubleshooting.
• The best practice is doing a standard Flutter install as your default/global SDK install and using FVM on a per-project basis. It allows for better compatibility and cleaner signals of what is happening behind the scenes.
• Make executable the default install recommended method for installing FVM.
• Implement version pinning in a more standard way. The Flutter team provides an "environment.flutter" pubspec parameter for pinning the version. It seems only to be supported by their internal tools; however, it would be an excellent way to provide a version pinning method that works across the community.
• Removing the global workflow, would open up for trimming down and simplification of FVM in general, and remove a lot of edge cases.
• Open for the community to maintain FVM-dependent tools, like GitHub Actions, Docker Images, etc.

If you get to this point, any feedback/suggestions would be appreciated it.

[EArminjon]

Little feedback from our team : we never used the global command from fvm. We installed fvm from brew (MacOs) and use it allow the .fvm config file. It's a pleasure to count on this cli. Never got issue, well done :) !

(No issue on our runners too <3)

[rodrigorahman]

Hello, I particularly think the deprecated of the global command is very bad.

There is a huge advantage in being able to switch Flutter versions based on a specific version think like this:

I am working from home office for 2 companies and both are a consultancy where they develop systems for many companies and each of these companies has a project for each different version.

Imagine the difficulty or work I have to configure the version I need in ALL projects and if by chance I open the terminal and run a flutter pub get or I want to leave the terminal running build runner. I will always have to replace the main command with some fvm and remember that in the heat of development it always generates many problems or even strange bugs that make us lose hours.

I see global activation as a pattern that is used by other languages such as nodejs and this is a pattern that is widely used in the market. And the FVM does it very well.

In my opinion what should be changed is the documentation with only 1 way to install (Brew, choco), because in my experience problems always occur when we install the FVM as a package. Perhaps this would avoid many problems like the one mentioned.

And also have an explanatory video on how to do the installation step by step, thus leaving a standard for use and also a FAQ with troubleshooting, for example, whenever you change the flutter version you must clear the packages cache, and other problems acquaintances.

In my opinion, configuration per project is a complicated item that raises a lot of doubt for those starting out, as it is much easier to teach a DEV to run a fvm global stable, fvm global 2.7.0 command than to teach a step-by-step how to it configures the flutter version within a project and how it checks if it is in the same version. Experience from over 900 students and many of them beginners.

;-)

[EArminjon]

I am considering leaving the global command as a manual configuration and stating that it is an experimental and advanced feature.

Please do keep it around. The global command is a huge timesaver for me. I never personally had issues with using it in the past 1.5 years since I started using fvm. Having to install and upgrade Flutter versions manually seems like a chore.

Question : What is your usage of fvm global ? I work since 3 years with flutter and manage more than 30 apps. I only use fvm and flutter inside project repository. I never use the global.

Without a global Flutter version, it's not possible to create a Flutter project by running fvm flutter create.

Create folder, fvm use 3.3.10 --force. fvm flutter create .

[Isuru-Nanayakkara]

I am considering leaving the global command as a manual configuration and stating that it is an experimental and advanced feature.

Please do keep it around. The global command is a huge timesaver for me. I never personally had issues with using it in the past 1.5 years since I started using fvm. Having to install and upgrade Flutter versions manually seems like a chore.

Question : What is your usage of fvm global ? I work since 3 years with flutter and manage more than 30 apps. I only use fvm and flutter inside project repository. I never use the global.

Without a global Flutter version, it's not possible to create a Flutter project by running fvm flutter create.

Create folder, fvm use 3.3.10 --force. fvm flutter create .

Then the .fvm directory gets created outside of the project directory, right. Do you keep it that way or move it inside manually?

[EArminjon]

if you did

mkdir myapp
cd myapp
fvm use 3.3.10 --force
fvm flutter create .

fvm and flutter are in the same folder. No sub project folder.

[Isuru-Nanayakkara]

if you did

mkdir myapp
cd myapp
fvm use 3.3.10 --force
fvm flutter create .

fvm and flutter are in the same folder. No sub project folder.

Gotcha! I missed the period. This is helpful. Thank you!

[leoafarias]

@leoafarias yes, of course!

First of all, let me explain why we have a specific workflow. Our company mostly uses Java and Node.js and there are two version management systems for them: SDKMAN and NVM. They both work the same way by updating local environment to point to a specific Java or Node version.

Our approach relies on the following:

1. We use native tools for each language for development processes (Gradle for Java and NPM for Node) as much as possible.
2. Our codebase is the single source of truth for the whole development lifecycle. That means that all development, debugging, CI/CI, etc tasks and configs (except for sensitive data like keys) are part of the source code.

So imagine the following, we might have a set of test tasks with different arguments passed to test runners. In Java we will create gradle tasks like testCi, testDev, etc and we are able to run them using gradle directly: $ gradle testCi. The same approach is taken for Node projects and tasks are defined as NPM tasks, so then we can run them like: $ npm run testCi. We are also able to use the exact same commands on any environment, we don't have to prefix them and they look and feel exactly the same as they are mentioned in official documentation for these tools (Gradle and NPM).

We are now also started developing Flutter apps and we have adopted Derry to run tasks defined in pubspec.yaml. For example, we have a watch task, which is defined as follows: watch: flutter packages pub run build_runner watch. And we run it by $ derry watch.

So here are multiple issues with your approach to FVM:

1. How do we even install Derry correctly? It should be installed globally, but when switching between Dart/Flutter versions, cached Derry binary causes crashes on start up.
2. Derry tasks might execute Flutter or Dart CLI commands, these will never be invoked through with FVM.
3. CI/CD environments are usually set up against specific Flutter version and they don't use FVM, that means now we have to remember when to prefix our commands with fvm and when not to.
4. This all leads to a situation that we cannot have our source code as a single source of truth and we have to remember when to do X and when to do Y.
5. This also leads to a situation where all other languages used in our company work one way yet Flutter/Dart works in a different way.
6. And as a bonus fvm prefix is not present in any docs for any Flutter tools. That just adds additional mental complexity.

In my opinion, this means that FVM is not fit for purpose for us. It doesn't work the same and expected way as similar tools for other languages do, it adds complexity and doesn't really solve the main problem - versioning of Flutter SDK.

Thanks for explaining your thoughts, @Auxx! It's important to note that FVM isn't trying to be a perfect tool for everyone using Flutter or meet every possible workflow. The main challenge with FVM is that Flutter doesn't make it easy to have multiple versions on the same machine, especially when it comes to pub dependencies. This means that FVM won't work like other tools such as NVM. However, I think the experience is close to it, and that's why I recommend moving global, which would allow for a clear version that manages the pub.dev dependencies.

While there may be workarounds for the issues you mentioned, such as using "alias" or the "exec" command, they may need to be optimized for your workflow. If you have specific use cases with Derry, feel free to open up an issue so we can take a look. Most of the other issues are out of FVM's control, to be honest.

[adamhalesworth]

I agree with @rodrigorahman. One of the benefits of fvm is that it works in a similar way to other tools such as nvm. Removing the option to set a global version might equally cause confusion (which is what led me here).

If this decision stems mostly/only from the perspective of troubleshooting a "non-standard" install, removing the global workflow to remedy this feels excessive and reduces fvm's usefulness.

Richer documentation or improvements to cli DX would be far more beneficial than deprecating core functionality.

[leoafarias]

@adamhalesworth, as I mentioned in my reply to @rodrigorahman, Flutter CLI tools are not optimized for version switching. I have done my best to provide context and messages when running commands that might cause issues, but the biggest challenge is that FVM depends on the global install, creating a circular dependency that can cause issues. All of these issues have fixes, but there is too much noise that comes from it.

[adamhalesworth]

Thank you for further highlighting the challenges on your side @leoafarias. There are so many moving parts to take into consideration, I know maintenance on fvm will not be easy and that these are difficult decisions to make.

Recommending the executable install method and retaining global as an advanced feature sounds like the ideal compromise. I have always installed fvm via brew which is likely why I have not come across the issues myself.

[leoafarias]

Since this has come up in another conversation. I believe there is plan forward for a simpler "global" version. That addresses the concerns while also simplifying the workflow.

[leoafarias]

Hello! FVM 3.0 is nearing completion and we're opening up Beta testing. If you're interested in hands-on testing and direct discussions about issues or use-cases, please sign up.
@adamhalesworth @Isuru-Nanayakkara @EArminjon @rodrigorahman @Auxx @kuhnroyal

https://forms.gle/n2Qm6zHX9aLc14gs7

[ManuelRauber]

Hi @leoafarias

I've seen that you will deprecate the global version with FVM 3.0.

That's unfortunate, because that's a thing people are using.

While I normally only work with local installs if possible, I've a project that require a global flutter installation.

The project uses a 3rd party that comes with a shell script. That shell script will directly call flutter ... and thus will use the global version.

With whatever I read in the FVM 3.0 sources the official way will installing the Flutter SDK globally and as well via FVM.

However, in that case there is no reason to use FVM 3.0 for that particular project, because I need to install the Flutter SDK globally anyway.

Now., the twist is: I have two projects with that 3rd party thing and they require different Flutter frameworks.

At the moment, I run fvm global before each project and it works as expected.

Do you have any other idea how to solve that?

[leoafarias]

Global will not be deprecated anymore. However I will provide guidance as I believe the overuse of global means most likely there is an incorrect use by a lot of people.

Version per project versioning should be thought as per project "global" we should have a beta this week.