Open Norbert515 opened 3 years ago
This issue is important because it is blocking the very wonderful detective.dev from working on Flutter Web. Upvoted!
Hard to say which one is correct. Tentatively marking as area-vm
. @bkonyi could you make a call and reassign the label if VM is right?
Mildly related, I'm experiencing issue where rootLib.uri
(desktop, macos) returns package:// uri instead of file:// uri (for the same script), which breaks DartCode attach to flutter functionality, since it uses the rootLib.uri to resolve package_config.json
location. Any idea why?
This is a DWDS issue. Unless there is a reason we can't or the VM behavior is clearly wrong we should always have DWDS match the VM behavior. In this case I think the VM behavior is preferred and I think DWDS running with Flutter Web should match it.
cc @annagrin
It looks like there are two issues here:
The first issue is that we are not returning the correct rootLib. The logic for that is here. It looks like we have a heuristic that probably works for pacakge:build_runner
and our internal Bazel
rules but doesn't work for Flutter Tools and the Frontend Server. This should be updated.
The second issue is that we are returning a package URI. This is intentional. We use the import URI contained in the DDC metadata files. We use the import URI because this is the URI that DDC understands. We use this convention throughout package:dwds
, for example here.
@grouma I will take a look at the incorrect rootLib (will check if it is due to reading libraries from the metadata)
We need to standardize whether we emit package uris or file paths for files technically outside of a package. This divergence has caused bugs in multiple tools now. I'm fine with converging in either direction (DDC or VM) but we need to converge. Modifying the VM implementation to match DDC would likely break more tools so by default I'm in favor of modifying DWDS to match the VM.
Agree with @jacob314.
I'd like to understand why we are using package:uris in the first place. In dart2js we track both import and file URIs together so we can choose the most appropriate on a given moment (import URIs are used for example when the identity of the import is relevant for semantic reasons, but file URIs are used when mapping source-maps and reporting location data, since most likely users need to fetch the file directly). Do we need to store both? Will file-Uris be sufficient in the DDC case?
cc @annagrin looked into this. The issue is that we have different bootstrapping logic which may wrap the main libraries. We should have enough information in package:dwds
to do the right thing for rootlibraries.
Update: This is taking some time to figure out correct solution that works for all our scenarios, will keep updating the thread.
Update: to solve this properly for all scenarios, we need to communicate the entrypoint from the build to the debugger (see mentioned issue above): https://github.com/dart-lang/webdev/issues/1290.
To unblock detective.dev, I am working on a better heuristic that works for this usage scenario and works well with other fixes (such as missing dart_sdk libraries: https://github.com/dart-lang/webdev/issues/1226
Note: the main isolate for web is actually not the same as for vm - flutter tools wraps the main in another dart file called "web_entrypoint.dart"
, so the correct web rootLib
looks like org-dartlang-app:/web_entrypoint.dart
.
@jacob314 @searchy2 will this difference matter to the tools you are developing?
Flutter_tools could artificially change the rootLib to the user's main if needed, once we have the app metadata in place.
@Norbert515 is developing detective.dev
I would love to use detective for speeding up development when building in Flutter Web.
@Norbert515 the PR above makes vmService.rootLib
returns org-dartlang-app:/web_entrypoint.dart
, which is the actual entry point of the app from the vm perspective on web platform. Will this work for your purposes?
After we add more metadata from the builds we will be able to change it to the user's main library, if it is still needed.
I use the rootLib for two purposes:
I suppose the PR would allow for 1 to work, but not 2. This would already be super helpful though.
@Norbert515 item 2 will take a bit longer as it requires the build to save the entrypoint in the metadata to work for all debugging scenarios.
Forgot to updated this. Part 1 from @Norbert515 's request is in current flutter stable.
When connecting to an application and invoking
getIsolate
, the root library differs depending on whether it is run on the web or not.The application it connects to:
Flutter doctor: