Ensure Dart version is at least as high as dependencies

[Levi-Lesches]

(Duplicating this from Workiva/dependency_validator#141, since I think this has value being integrated into Pub directly).

---

Say I have the following project:

environment:
  sdk: ^3.0.0

dependencies:
  pubspec_parse: ^1.5.0

This compiles, and Pub doesn't complain. However, pubspec_parse version 1.5 requires Dart 3.6! Everything works because, coincidentally, I happen to have Dart 3.6 on my PC. But someone else might not, especially a CI workflow (this happens to me all the time). I have a use case where I need to be entirely offline, so I'd like to know if I need to upgrade my Dart SDK as far in advance as possible. In general, I want to know when updating a dependency will cause my project's minimum Dart version to increase

As for transitive dependencies, it's probably safer to check each package in .dart_config/package_config.json and flag the highest Dart version required by any dependency, preferring to show direct dependencies when possible.

[sigurdm]

The sdk constraint is for the package itself, and doesn't cover the dependencies. It is a bit confusing, but I think it makes the most sense

Consider the case where a new version 1.5.1 of pubspec_parse was published with a lower sdk constraint. Now the project actually would work with the older sdk.

The sdk constraint is also used for specifying the language version, so that might be one reason to leave it lower than the dependencies.

If you look at the pubspec.lock, it has a section at the bottom like:

sdks:
  dart: ">=3.5.0 <4.0.0"

It specifies the intersection of all sdk constraints of all packages in the resolution.

I remember discussing this before, but cannot find the exact issue to link.

Closest I could find was this: #2007

[Levi-Lesches]

Consider the case where a new version 1.5.1 of pubspec_parse was published with a lower sdk constraint. Now the project actually would work with the older sdk.

1. You can say that about regular dependencies too: say win32: 1.0.0 depends on ffi: 1.1.0, so you depend on ffi: ^1.1.0. Now, win32: 1.1.0 downgrades to ffi: 1.0.0 -- you're still using ffi: 1.1.0 because that's what it used to be. That's what you needed at the time to make your project work, and even though you could change it now, you don't have to.
2. I'd wager the opposite cases happens a lot more often: packages (rightfully, IMO) consider moving from, eg, Dart 3.3 to Dart 3.6 as a non-breaking change, and so they'll do it often. That doesn't cause my code to break, but it does cause my environment to break. I'd need to upgrade Dart/Flutter, test locally, then open a PR only to realize the hard way I forgot to upgrade the CI as well.

In other words,

I think it makes the most sense

The sdk constraint is also used for specifying the language version, so that might be one reason to leave it lower than the dependencies.

having the pubspec declare an SDK version lower than the dependencies is misleading because you can't actually run the project with the version you see in front of you, and instead have to "just try it" and see what you need.

The bigger problem is that if the developer happens to have a recent version of Dart/Flutter, they won't even notice that running dart pub upgrade is causing their minimum SDK version to increase. This can be problematic for package authors, who won't update the changelogs appropriately and thus cause a domino effect where other packages that depend on it also won't realize. It's also an issue for offline uses like mine, where I develop on my laptop, with WiFi, then deploy to my devices over SSH without an internet connection and see that I can't run the code anymore. And of course, there's the case about CI.

Having an error/warning when the pubspec SDK version isn't high enough should fix those issues. But it would also be helpful if dart pub upgrade could respect a pinned language version. So if I have sdk: 3.5.0, (no ^), it shouldn't upgrade to any packages that need 3.6.0. That way I can safely run dart pub upgrade and trust that my offline SDK will be able to run with the new packages.

[Levi-Lesches]

Here is another, related error message, caused by having flutter: ^3.22.0 and ffigen: ^16.0.0

Resolving dependencies...
Note: meta is pinned to version 1.12.0 by flutter from the flutter SDK.
See https://dart.dev/go/sdk-version-pinning for details.
Because analyzer >=6.5.1 depends on meta ^1.15.0 and analyzer >=6.5.0 <6.5.1 depends on meta ^1.14.0, analyzer >=6.5.0 requires meta ^1.14.0.
And because every version of flutter from sdk depends on meta 1.12.0, flutter from sdk is incompatible with analyzer >=6.5.0.
And because ffigen >=16.0.0 depends on dart_style ^2.3.7 which depends on analyzer ^6.5.0, flutter from sdk is incompatible with ffigen >=16.0.0.
So, because flutter_local_notifications_windows depends on both flutter from sdk and ffigen ^16.0.0, version solving failed.

The error makes sense:

• flutter 3.22 is pinned at meta 1.12
• ffigen 16.0 requires dart_style 2.3.7
• dart_style 2.3.7 requires analyzer 6.5.0
• analyzer 6.5.0 requires meta ^1.14, which conflicts with Flutter 3.22

Of course, on my system I have the latest Flutter, which doesn't bring up these issues. The problem comes up because I've asked that my project be compatible with Flutter 3.22, which means only my CI (or worse, a user) will encounter this issue, and not me.

Again, the errors make sense, but what's very confusing here is having a pubspec that says "my project should be compatible with Dart XXX and Flutter YYY", and Pub lets you do that, even though that's not the case, and you have to figure that out the hard way. And as I mentioned, running dart pub upgrade shouldn't get into this situation. This change was actually suggested by dependabot, who also thought it was safe.

Now, the Flutter case is different, since I'm not sure how Pub should just "know" that Flutter used to pin to a different version of meta. I'm not sure if Flutter has the equivalent of a pubspec who's older versions can be easily queried like packages on Pub can. I can open a new issue at flutter/flutter if needed, but I think the root cause is going to be the same for Dart as well.