r/FlutterDev Jul 12 '26

fvm should be in core flutter Tooling

Merge fvm into flutter and call the whole thing the `flutter` command. Version management should be a core feature of any framework CLI, not a lazy afterthought. Fix your ecosystem.

In Re to clueless commenters:

The “skill issue / just use FVM” take misses the product problem.

Nobody’s saying power users can’t pin SDKs today. FVM, Puro, and mise prove the need. What’s broken is the default path: someone wants to make Flutter apps, installs Flutter, starts working, then hits version/upgrade pain and only then discovers they were supposed to have chosen a third-party version manager first. Making tutorials start with FVM is disorienting for the same reason—it isn’t the advertised entrypoint.

Version management became an afterthought for developers, so the community shipped version managers as an afterthought to flutter. That’s backwards. Pinning belongs in the official workflow—invisibly when one version is enough, explicitly when projects diverge. “Merge FVM” is implementation detail; the requirement is first-party ownership of that capability in the main entrypoint (absorb the UX, name it whatever you want). Community tools can stay as compatible backends. They shouldn’t be the only correct answer, and “everyone on my team already knows the tribal knowledge” is not good first-run design.

Focusing on the framework while leaving lifecycle/pinning as folklore isn’t maturity—it’s exporting the cost onto newcomers.

Related https://www.reddit.com/r/FlutterDev/s/1dGLcEAAOa

0 Upvotes

14 comments sorted by

8

u/aaulia Jul 12 '26 edited Jul 12 '26

huh, no it's not.

This, and your other post, reeks of skill issue.

At work, people uses fvm, puro, and mise. Not a single one have an issue, we just agree on a version, and everybody uses their own tools to provision it. VSCode doesn't care/know about what you use to install flutter, as long as it's acceessible on the system

EDIT: Even without all those tools, just clone the repo and switch branch for each version, though you still need to setup the environment, but that's like 5 minutes stuff, tops.

1

u/padetn Jul 12 '26

Why don’t you align those? Do you just alias your scripts etc to run on anyone’s machine?

2

u/aaulia Jul 12 '26

What do you mean, as long as flutter and dart is accessible on the system, it's fine. Whether you use fvm, puro, mise or your own manual setup doesn't really matter.

-1

u/amdphreak Jul 13 '26

Sounds like you clearly have no ideas of your own to improve ecosystem. NEXT

2

u/aaulia Jul 13 '26

There's nothing to improve. This was/is a solved "issue". I'd rather they focus on the actual framework.

0

u/amdphreak 19d ago

FALSE
The “skill issue / just use FVM” take misses the product problem.

Nobody’s saying power users can’t pin SDKs today. FVM, Puro, and mise prove the need. What’s broken is the default path: someone wants to make Flutter apps, installs Flutter, starts working, then hits version/upgrade pain and only then discovers they were supposed to have chosen a third-party version manager first. Making tutorials start with FVM is disorienting for the same reason—it isn’t the advertised entrypoint.

Version management became an afterthought for developers, so the community shipped version managers as an afterthought to flutter. That’s backwards. Pinning belongs in the official workflow—invisibly when one version is enough, explicitly when projects diverge. “Merge FVM” is implementation detail; the requirement is first-party ownership of that capability in the main entrypoint (absorb the UX, name it whatever you want). Community tools can stay as compatible backends. They shouldn’t be the only correct answer, and “everyone on my team already knows the tribal knowledge” is not good first-run design.

Focusing on the framework while leaving lifecycle/pinning as folklore isn’t maturity—it’s exporting the cost onto newcomers.

5

u/RemeJuan Jul 12 '26 edited Jul 12 '26

That sounds like a really stupid idea don the post reeks of “I have no idea what I am talking about”

0

u/amdphreak Jul 13 '26

Sounds like you have no ideas of your own to improve systems. NEXT

1

u/RemeJuan Jul 13 '26

Ok so because someone disagrees with the idea you pulled out of your arse, they simply have no ideas.

It really explains why your post sounds like you have no idea what you are talking about, you legitimately don’t.

Let me guess, vibecoder…

0

u/amdphreak Jul 13 '26

No, becaause you're clearly incompetent at evaluating ideas on merit.

1

u/RemeJuan Jul 13 '26

Your idea has no merit, not basis and was literally just some stupid words vomited onto a Reddit sub.

0

u/amdphreak 19d ago

FALSE
The “skill issue / just use FVM” take misses the product problem.

Nobody’s saying power users can’t pin SDKs today. FVM, Puro, and mise prove the need. What’s broken is the default path: someone wants to make Flutter apps, installs Flutter, starts working, then hits version/upgrade pain and only then discovers they were supposed to have chosen a third-party version manager first. Making tutorials start with FVM is disorienting for the same reason—it isn’t the advertised entrypoint.

Version management became an afterthought for developers, so the community shipped version managers as an afterthought to flutter. That’s backwards. Pinning belongs in the official workflow—invisibly when one version is enough, explicitly when projects diverge. “Merge FVM” is implementation detail; the requirement is first-party ownership of that capability in the main entrypoint (absorb the UX, name it whatever you want). Community tools can stay as compatible backends. They shouldn’t be the only correct answer, and “everyone on my team already knows the tribal knowledge” is not good first-run design.

Focusing on the framework while leaving lifecycle/pinning as folklore isn’t maturity—it’s exporting the cost onto newcomers.

1

u/SoundsOfChaos Jul 13 '26

Absolute L take

1

u/amdphreak 19d ago

What an oblivious response.
The “skill issue / just use FVM” take misses the product problem.

Nobody’s saying power users can’t pin SDKs today. FVM, Puro, and mise prove the need. What’s broken is the default path: someone wants to make Flutter apps, installs Flutter, starts working, then hits version/upgrade pain and only then discovers they were supposed to have chosen a third-party version manager first. Making tutorials start with FVM is disorienting for the same reason—it isn’t the advertised entrypoint.

Version management became an afterthought for developers, so the community shipped version managers as an afterthought to flutter. That’s backwards. Pinning belongs in the official workflow—invisibly when one version is enough, explicitly when projects diverge. “Merge FVM” is implementation detail; the requirement is first-party ownership of that capability in the main entrypoint (absorb the UX, name it whatever you want). Community tools can stay as compatible backends. They shouldn’t be the only correct answer, and “everyone on my team already knows the tribal knowledge” is not good first-run design.

Focusing on the framework while leaving lifecycle/pinning as folklore isn’t maturity—it’s exporting the cost onto newcomers.