Use case

One of the biggest pain points for package authors (and probably app developers too) that have been brought up during the Dart & Flutter Package Ecosystem Summits is that Flutter has pinned versions of its dependencies.

Why do we not want pinned dependencies? Because it leads to a lot trickier dependency version resolution than it needs to be for the end user. I would say almost all Flutter developers have at some point ended up in dependency resolution hell, before they realize that some dependencies needs to be treated with special care.

Since all of the pinned dependencies are controlled by Google it should be fairly straight forward to set up a process so that they all have some tests towards Flutter before doing a new non-breaking release or doing deprecations.
The main ones are: intl, meta, collection path, vector_math and async.

The Flutter team’s rationale for using pinned versions is outlined in this document but I have been told that removing the dependency pinning is on the radar, so I just want to open this so that we can track it somewhere.

Proposal

Things that needs to be solved:

• Flutter builds should be hermetic.
• When dependencies bump their versions they should not be able to break Flutter.

For the first one I'm thinking that it could be solved with a lock file that isn't shipped with Flutter, but used for the builds.

For the second one my suggestion is that we introduce CI checks that needs to run before releasing a new version of the dependencies to make sure that they don't break anything in Flutter. Deprecations have to be taken into consideration here too, since they are not counted as breaking in semver.