Recognize file entry-points that should be accessed as package URIs

[lrhn]

Users provide entry points to our tools as command line arguments. In some cases those entry points are inside a the lib directory of the package the user is working on, but are specified as file paths.
This can cause the same library file to be imported both using a file URI and a package URI, causing it to be interpreted as two different libraries.

To help users, we should vet the entry point path against its package configuration, and if the entry point could be referenced using a package URI, use that package URI as the URI of the entry-point instead.

[natebosch]

What does "entry point" mean in this context? Is it "Dart library with a main() method?"

[peter-ahe-google]

It means a reference to something you can run the tool on. It doesn't need to have a main method, and it doesn't need to be a library. For example, you can run both dartfmt and the analyzer on part files.

[lrhn]

Yes, any user supplied file name, as long as there is also a way to resolve package URIs.

For application entry points (library containing the main method), we search for a .packages file relative to that library.

Purely single-file or source based tools, like the formatter, usually don't care what URI the library is identified by, so there is no reason to exempt them.

[peter-ahe-google]

For application entry points (library containing the main method), we search for a .packages file relative to that library.

Actually, we would search for a .packages file for any entry point.

[brianegan]

This would be amazing! I've had a lot of issues filed on my projects related to this very problem. A few examples:

flutter_redux:
brianegan/flutter_redux#35
brianegan/flutter_redux#36

scoped_model:
brianegan/scoped_model#15

This is just the tip of the iceberg :)