pubspec.lock sometimes doesn't work as a lockfile

[gnprice]

If I run flutter pub get right now, it bumps the version of several of our dependencies:

$ flutter pub get
Resolving dependencies... 
  _fe_analyzer_shared 58.0.0 (59.0.0 available)
  analyzer 5.10.0 (5.11.1 available)
  device_info_plus 8.2.0 (8.2.1 available)
  file_picker 5.2.10 (5.2.11 available)
  flutter_plugin_android_lifecycle 2.0.9 (2.0.12 available)
  lints 2.0.1 (2.1.0 available)
  path_provider_android 2.0.25 (2.0.26 available)
  path_provider_windows 2.1.5 (2.1.6 available)
  share_plus 6.3.2 (6.3.3 available)
> test 1.24.2 (was 1.24.1)
> test_api 0.5.2 (was 0.5.1)
> test_core 0.5.2 (was 0.5.1)
  url_launcher_linux 3.0.4 (3.0.5 available)
  url_launcher_windows 3.0.5 (3.0.6 available)
  vm_service 11.3.0 (11.4.0 available)
  win32 3.1.4 (4.1.3 available)
Changed 3 dependencies!

Namely test, test_api, test_core. It edits the pubspec.lock file to reflect these changes.

We've had this happen several times before: 2b3e781, 0b89ce9, 265143d.

This doesn't fit with what I would think the meaning of pubspec.lock is, and the meaning of flutter pub get: I expect the former to serve as a lockfile, and the latter to be the command that respects the lockfile and just installs the exact same versions of our dependencies as the lockfile specifies. There's a different command, flutter pub upgrade, for when one wants to update what's in the lockfile.

And in keeping with my expectations, flutter pub get leaves most of the dependencies in place, as the output above shows. By contrast if I run flutter pub upgrade, it upgrades 15 dependencies instead of 3 (or 12 dependencies, if I do so after flutter pub get).

(All the same observations apply if I type dart pub get and dart pub upgrade. It seems like the flutter versions are thin wrappers over the dart versions; I'm not sure if there's any difference at all.)

I'm not sure if this behavior of occasionally upgrading a few dependencies is just a bug in pub, or reflects some subtlety of pub's intended behavior, or somewhere in between. I'm hoping it's a bug that can just get fixed, because it seems pretty inconvenient. Lockfiles were a good invention.

---

One possible diagnostic factor is that we use Flutter from the main/master channel. Perhaps these updates reflect changes in Flutter's own dependencies? If that is what's driving this, then it adds a further reason for pinning our Flutter SDK version too, i.e. #15.

In that case, the upstream issue is just that when a mere dart pub get causes dependencies in pubspec.lock to change, there should be some message explaining why.

[gnprice]

One possible diagnostic factor is that we use Flutter from the main/master channel. Perhaps these updates reflect changes in Flutter's own dependencies?

OK, I now consider this diagnosis confirmed.

At https://api.flutter.dev/ , there's a list of "supporting libraries that ship with Flutter". That list includes almost all of the packages that we've seen updated in this way:

async
collection
material_color_utilities
meta
source_span
test_api

(where collection is one I see an update for right now, which I'll push soon.)

The two exceptions — the two packages we've seen updated this way that aren't on that list of "supporting libraries" — are test and test_core. But: those packages are unusual in having an exact dependency on test_api. The point of test_api is precisely to force test and a few closely-related packages to be upgraded in lockstep. So those exceptions are equally well explained by changes in Flutter's dependencies.

I think for our own purposes the solution is therefore:

• Pin a precise version of Flutter #15

The other remaining action item is to see if there's an existing ticket for the upstream issue here:

In that case, the upstream issue is just that when a mere dart pub get causes dependencies in pubspec.lock to change, there should be some message explaining why.

and if not, then file one. Hopefully the behavior here can be less confusing and more transparent for future users of Flutter main.