Seeing issues when an older package:file is run on a newer SDK

[devoncarew]

Seeing issues when an older package:file is run on a newer SDK

[aam]

have package:glob depend on at least 6.1.3 of file

Looks like dependencies were updated on main branch already(dart-lang/glob@d069e13), but the version has not been published yet.

[devoncarew]

I opened a PR (dart-lang/glob#65) for the package:glob publish and filed dart-lang/test#1784 to track updating the glob dep in package:test.

[aam]

I guess we haven't hit this issue more often is because it only affects projects that don't already have a direct dependency on package:file.
flutter, for example, does have direct dependency (https://github.com/flutter/flutter/blob/master/packages/flutter/pubspec.yaml#L29) and was updated as part of the dart sdk change roll out.

[devoncarew]

Yeah, I think people using flutter test will be OK, since they'll get a version of file which works with the new SDK.

I've hit this for a few projects - always when running dart test (I need to pub upgrade that project for things to work again).

[jakemac53]

I left a note in the package:test issue, but upgrading dependencies in those packages won't have any positive effect afaik. In all but the most obscure scenarios a user would always get the latest glob when upgrading their version of package:test.

People have to run dart pub upgrade or the flutter equivalent regardless.

[devoncarew]

I've hit this issue several times - always for existing projects. dart pub upgrade would have prevented the issue, but users won't know to run that when they hit the issue.

Shipping new versions of the package will also help the dart pub downgrade use case - allowing people to test that the version ranges of their deps are correct (currently, that command just won't work in 2.19, since test can't run tests w/ an older package:file on 2.19).

[jakemac53]

I've hit this issue several times - always for existing projects

This won't help existing projects - they will be on an old version of package:test and won't see the constraint.

Shipping new versions of the package will also help the dart pub downgrade use case - allowing people to test that the version ranges of their deps are correct (currently, that command just won't work in 2.19, since test can't run tests w/ an older package:file on 2.19).

Do we have any idea how many people use that? I doubt it is many.... in theory it is nice but in the past it has been very slow to run and generally people just don't bother from what I have seen. I haven't seen anybody file an issue about this which was related to pub downgrade (I really don't think anybody uses it at all).

In general, there isn't an expectation for packages to rev versions of their deps like this, and I really don't want to set that precedent.

[devoncarew]

I haven't seen anybody file an issue about this which was related to pub downgrade (I really don't think anybody uses it at all).

This was why glob's dep was rev'd - because of this specific failure when trying to run dart test after a dart pub downgrade (dart-lang/glob#62). I expect the only time downgrade is generally run is on a CI, and this issue will essentially break the dart pub downgrade use case.

To be clear, the front end cannot build the dart test snapshot on 2.19 if it's using an older version of package:file. I think the package deps should reflect the state of the world that we need to build+run a package.

In general, there isn't an expectation for packages to rev versions of their deps like this, and I really don't want to set that precedent.

Can you elaborate on the precedent? We don't change Dart APIs in backwards incompatible ways very often, but when we do, we should do what we can to mitigate the user pain.

[jakemac53]

Chatted a bit with Devon offline - there were two possible steps to alleviate this issue that came from that:

• We could mark the old versions of package:file as "bad" in pub (not sure how many versions back we would want to do that for). This should give an early warning to users on pub get today, and prevent new users from getting those versions.
• The dart tool could add some functionality to recognize this error and tell the user more directly how to solve it (upgrade deps). Possibly it would just link to an article describing the issue and fix.
  • This wouldn't help usage outside of the dart command line but should cover the majority of cases.
  • Would be better than hacking pub in some way, could possibly be a generalized feature for the dart tool, to recognize specific errors and provide suggestions.

[dnfield]

I think there's a somewhat general problem here. Alex and I both didn't think to bump the SDK constraint when updating package:file, but even if we had pub would still have said "oh you have 6.12 and its upper bound is < Dart 3.0.0, so you can keep using it" even if it could see that 6.13 more tightly satisfies your actual SDK version.

As a package author, I wish pub would treat environment constraints more tightly. If it did, I could mark file 6.13 as bad (it claims to be compatible with an SDK it is not) and publish file 6.14 with a tighter SDK constraint and know that my customers would get the right version.

I'm unclear about whether to mark the old versions as bad. If you're on an SDK before this change was introduced you need that "bad" version. But it also claims to be compatible up through version 3.0.0, which of course it is not.

[devoncarew]

I agree there's a general problem here, but just to clarify your comments above; 6.1.2 is 'bad' on Dart 2.19-dev (not 6.1.3). 6.0.0 - 6.1.2 won't be happy on Dart 2.19; 6.1.3 (and 6.1.4) would be fine on either newer or older SDKs.

[jakemac53]

Right, it should be fine to mark them as "bad". While technically it works on older SDKs we still want those people to upgrade so that when they get the new SDK it still works.

And yes there are a few more general issues:

• If you implement an API from another package, set your range to < the next minor release, not major release. Packages generally expect to be able to add methods, non-required params, etc to classes and not have to do a breaking change. So package:file should have never had a constraint like <3.0.0, since it implements File.
  • Maybe pub could help users here?
• There is no way to retroactively limit which sdks a package is available on.
  • Possibly pub could add a feature that allows you to attach some extra metadata to package versions, which further restricts the SDK constraint beyond what is in the pubspec. What to do on pub get for people who have now invalid versions after such a change is made is an open question.