Dependencies can be more than imports or used binaries

From the README:

Some packages are not imported by any dart files but are used for their executables.

Based on this sentence I'm assuming that only import statements are found programatically. There is another way that a dependency can sneak in that you might want to consider, or at least warn in the readme so it can be treated the same way as executables.

If a class is returned from an API that isn't defined in the package, you can silently be depending on a method signature defined in some other package that you might not import.

import 'package:b/b.dart' as b;
// no import to package:c

void main() {
  b.someBMethod().someCMethod();
  // If someBMethod returned a class from C I have an implicit dependency on C
}

Here package:b could plausibly move to a new version of package:c without a breaking change version bump.

With type inference this 'type leaking' can happen in sneaker ways:

import 'package:b/b.dart' as b;
// no import to package:c

void main() {
  // Assume someBMethod has the signature: int someBMethod(C c)
  var x = someBMethod;
  x = (value) => value.someCMethod();
 // due to type inference I got autocomplete and would now break if someCMethod is renamed.
}

Start with the dependency rules described in the README, especially the passage about imports and executable usage. Determine whether dependencies exposed through inferred or returned API types should be detected, warned about, or only documented; done requires a defined behavior and corresponding validation.