In most of my recent projects I've been using Flutter Version Management (FVM) to manage Flutter versions. I've noticed that the .fvm directory is commonly listed in .gitignore and thus not tracked in Flutter project repositories, which makes sense - it is not necessary to keep the whole Flutter SDK in version control.
Excluding the whole .fvm directory also excludes .fvm/fvm_config.json file. I'm curious to understand why is it not excluded from .gitignore (e.g. !.fvm/fvm_config.json
), given the apparent benefits of including it in source control:
Version Consistency: The file ensures that all developers working on the project use the same Flutter version, reducing compatibility issues and the "it works on my machine" problem.
Ease of Setup: New team members or contributors can quickly set up their development environment by running fvm install, as the correct Flutter version will be automatically installed.
Convenient Updates: Updating the Flutter version can be easily managed through this file, ensuring that all team members are updated simultaneously when they pull the latest code.
Non-Intrusive: For developers not using FVM, this file does not interfere with their existing workflow or Flutter setup.
Considering these benefits, it seems logical to include .fvm/fvm_config.json in source control. Yet, I've observed that it's not a common practice. Is there a specific reason behind this? Are there disadvantages or potential issues that I'm overlooking which justify its exclusion from version control? The required version of Flutter could also be included in the documentation instead (e.g. README file or the project Wiki page), but I don't see the benefit over having it in the config file ready to be installed with just one command.
I think that strongly depends on the personal preferences of the team/individual. You're right, if we exclude the file from the gitignore, then everyone would have the correct FVM config. The problem I see with this approach is that if you want to add a separate feature in its own branch and this branch requires a specific version of Flutter to run, and you merge this version into the dev/main/prod branch for some reason, you overwrite the running version for everyone. Additionally, there would be more merge conflicts if everyone can push their own version. Some developers want to be flexible with the version they work with. Some also use specific CI/CD pipelines where the Flutter version is defined; in this case, it doesn't matter what is specified in the fvm_config.json.
But, as mentioned, it varies from team/project. Do what suits you best. For instance, I found this Flutter handbook that seems quite good at first glance, providing many good best practices. In the FVM exclusion category, they also exclude the fvm_config.json from the gitignore.
Only commit that json file, the sdk symlink should not be included. To do that add to gitignore:
.fvm/*
!.fvm/fvm_config.json
Link to the handbook: https://infinum.com/handbook/flutter/basics/flutter-version-manager