New error message for depend_on_referenced_packages quick-fix

[FMorschel]

I have a use case for a change in depend_on_referenced_packages quick-fix error message.

In my company we create some local packages. They sometimes depend on each other.

Just now I was editing a package, let's call it a, that has a dependency in a second package b which ultimately depends on c.

When I wrote down some code that needed package c and then added the import line, I got a this lint:
The imported package 'c' isn't a dependency of the importing package.

But when trying to use the assist I got an error.

[a] flutter pub add c
Because a depends on c any which doesn't exist (could not find package c at https://pub.dev), version solving failed.
exit code 65

But (I believe) the analysis server knows that my b package depends on a c package from path.

I dont't think the analyzer should be able to figure out the path from both packages to solve where c is at in my machine, but shouldn't it at least show me that the dependency is not from pub.dev?

I have not tested but it got me guessing about dependencies that rely on GitHub repository links or similar. What then? If I need something that is not in release yet I'll need to manually change there anyway so the quick-fix would not be actually helping but IMO it would be generating doubts.

[bwilkerson]

Those are good point. It does seem like server ought to minimally be able to tell whether the package_config.json file maps the package name to a directory inside the .pub-cache directory, and if not it shouldn't offer the fix.

Whether it's worth looking in the pubspec.yaml files to figure out the right way to depend on non-pub-provided packages is another question, but it minimally shouldn't be creating new issues that might be even more confusing for users.

[DanTup]

It's possible this fix is coming from Dart-Code and not the server. Although we do call pub for a few things in server now, at one time it seemed like an odd thing to do and Dart-Code was already doing it (and has an "Add Dependency" command), so we include a code action to trigger the command for some kinds of diagnostics:

https://github.com/Dart-Code/Dart-Code/blob/master/src/extension/providers/add_dependency_code_action_provider.ts

The implementation is pretty basic so it's no surprise if there are edge cases. Perhaps moving it to server and fixing this issue together would make sense (because server has much better understanding of the projects than Dart-Code does).

[bwilkerson]

Yes, in general we should have as much support as possible in the server.