Bump analyzer and glob dependencies to avoid errors after running "pub downgrade"

[DanTup]

If you create a package like this:

name: foo
version: 1.0.0

environment:
  sdk: '>=3.0.0 <4.0.0'

dependencies:

dev_dependencies:
  test: ^1.26.2

Then run pub downgrade, you end up unable to run tests:

Failed to build test:test:
/D:/Caches/Pub/Cache/hosted/pub.dev/watcher-1.0.0/lib/src/constructable_file_system_event.dart:7:57: Error: The class 'FileSystemEvent' can't be extended, implemented, or mixed in outside of its library because it's a sealed class.
abstract class _ConstructableFileSystemEvent implements FileSystemEvent {

This is because you get pkg:watcher v1.0 which is broken on Dart 3 because FileSystemEvent is marked sealed (watcher correctly says it's not compatible with 3.0, but because of this it is treated like it is). The reason you get pkg:watcher v1.0 is because pkg:analyzer up until v6.4.0 allows it.

Therefore, I think it would be sensible to bump the analyzer version constraint here to a minimum of 6.4.0.

However, if you force that, you then get:

Failed to build test:test:
/D:/Caches/Pub/Cache/hosted/pub.dev/file-6.0.0/lib/src/interface/file.dart:15:16: Error: The method 'File.create' has fewer named arguments than those of overridden method 'File.create'.
  Future<File> create({bool recursive = false});

Because pkg:file is also broken before 6.1.3. This is allowed by pkg:glob v2.0, but fixed in pkg:glob v2.1.1.

So, the following works:

dev_dependencies:
  test: ^1.26.2
  # these are needed to avoid failures to run `test` if you run `pub downgrade`
  glob: ">=2.1.1"
  analyzer: ">=6.4.0"

While it's probably not common to run pub downgrade, I think it would be sensible for new versions of pkg:test to have these minimums so someone depending on the latest version of test can't get broken transitive dependencies if there's nothing else pulling them up.

@jakemac53 fyi - I'm filing this instead of a PR because there may be reasons not to do this or I may have misunderstood something, but I'm happy to open a PR if this sounds sensible.

(cc @FMorschel who found this after using pub downgrade to try and reproduce/fix some issues reported by pana that were affecting Pub package scores).

[jakemac53]

In general I am opposed to bumping dependencies versions just to pick up bug fixes, I do not believe there is any scenario other than pub downgrade that it actually helps. And it's just one of many reasons that pub downgrade is unfortunately not a very useful tool in practice.

To outline some specific scenarios here:

• Existing users will just be able to select the old version of test, so they can still get these bad packages. It only helps new users who use pub add test --dev or explicitly depend on or upgrade to the latest version of test.
• Even for the users it does "help" - the scenario this is intended to resolve is one where a user for some reason is forced into an older version of one of these packages - however they still won't be able to get those new versions, they will just get a version solve error now instead. Maybe this is a slightly better error but they are still broken.
• Meanwhile, it's possible some users are on older SDKs, stuck on these older versions of packages, which are actually what they need. Keeping the constraints lower allows those users to pick up newer versions of package:test, so we maintain compatibility with a wider range of SDKs (probably not relevant in this case due to our min SDK constraint, but as a general statement this is true).

Because of this I think version constraints should only be used to express a packages API compatibility with its dependencies and nothing else.

[DanTup]

Existing users will just be able to select the old version of test, so they can still get these bad packages

Sure, but this doesn't seem like a reason not to fix it. If you choose an old version of a package, you may get bugs that are fixed in later versions, that's understandable.

they will just get a version solve error now instead. Maybe this is a slightly better error but they are still broken.

A version solve issue is surely much better than a compile and/or runtime error?

Meanwhile, it's possible some users are on older SDKs, stuck on these older versions of packages, which are actually what they need.

pkg:test already requires Dart 3.5, which is higher than any of the other involved packages, so I don't think anyone can get back to a version of the SDK that doesn't trigger this issue using the latest pkg:test.

Because of this I think version constraints should only be used to express a packages API compatibility with its dependencies and nothing else.

I understand, but I feel like the distinction here is not that useful. dart test on a > Dart 3.0 SDK (which is all it supports) is broken using older versions of the packages than noted above. While using pub downgrade might not be common, it is a documented feature that is intended to keep you with compatible packages. It's not clear to me who can benefit from allowing the incompatible (for some definition of incompatible) versions.

(FWIW, I feel like the real issue here was Pub treating "<3.0" as "<4.0" when there were breaking changes like this, but I'm sure this was weighed up, and that ship has well sailed!).

If I've not convinced you, feel free to close - it's certainly an edge case, just one that tripped both of us up, and since I'd spent the time debugging I thought I should raise the question. It's rather fiddly to figure out what the problem is and there isn't an obvious fix ("don't use some subset of packages that are valid according to the constraints" is a bit woolly).

Thanks!