Sdk: Recognize file entry-points that should be accessed as package URIs
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.
lrhn
All 17 comments
What does "entry point" mean in this context? Is it "Dart library with a main() method?"
natebosch
on 9 May 2018
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.
peter-ahe-google
on 9 May 2018
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.
lrhn
on 9 May 2018
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.
peter-ahe-google
on 9 May 2018
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:
https://github.com/brianegan/flutter_redux/issues/35
https://github.com/brianegan/flutter_redux/issues/36
scoped_model:
https://github.com/brianegan/scoped_model/issues/15
This is just the tip of the iceberg :)
brianegan
on 6 Jun 2018
Another example of this issue, this time on Stack Overflow: https://stackoverflow.com/questions/50913869/flutter-a-value-of-type-lib1object-cant-be-assigned-to-a-variable-of-type-li
lrhn
on 19 Jun 2018
This is now the main issue for tracking this problem.
What does this have to do with the CFE, though? Wouldn't this be handled by the analyzer?
matanlurey
on 18 Jul 2018
What does this have to do with the CFE
My understanding of the proposal is that the CFE would automatically treat lib/some_file.dart as package:the_package/some_file.dart. This isn't a warning to the user - it's accepting the pattern and attempting to do what the user expects.
natebosch
on 18 Jul 2018
Oh, love it!
matanlurey
on 18 Jul 2018
Until this is solved, can we add a TL;DR for users that followed the various bug threads to here for what the bug is and what is the temporary workaround?
xster
on 26 Jul 2018
@xster I was thinking if it were a good idea to add a comment to lib/main.dart generated by flutter create to not use relative imports in this file and to not import this file from anywhere.
zoechi
on 27 Jul 2018
Face the same problem.
This problem is easily overlooked during development, please fix it.
xuexin
on 12 Sep 2018
@peter-ahe-google are you still looking at this?
mit-mit
on 24 Sep 2018
It's next on my todo list.
peter-ahe-google
on 24 Sep 2018
Proposed fix https://dart-review.googlesource.com/c/sdk/+/78246
peter-ahe-google
on 5 Oct 2018
Is it possible that the fix will be included in the Dart 2.1 release?
vanesyan
on 10 Oct 2018
@vanesyan it's looking good, but I can't promise anything.
peter-ahe-google
on 11 Oct 2018
Related issues
nex3
路
3Comments
jmesserly
路
3Comments
55555Mohit55555
路
3Comments
emilniklas
路
3Comments
DartBot
路
3Comments
Most helpful comment
My understanding of the proposal is that the CFE would automatically treat
lib/some_file.dartaspackage:the_package/some_file.dart. This isn't a warning to the user - it's accepting the pattern and attempting to do what the user expects.