search

dart-lang / webdev

A CLI for Dart web development.
https://pub.dev/packages/webdev
212 stars 75 forks source link

When debugging a webdev app from VS Code, hitting a breakpoint opens copy of actual file #2383

Open elliette opened 7 months ago

elliette commented 7 months ago

It seems like when we hit a breakpoint, we are downloading a copy of the source instead of mapping it to a local source on disk. See for more details and repro steps: https://github.com/Dart-Code/Dart-Code/issues/5024

DanTup commented 7 months ago

To be clear, what's happening here is that the source has an org-dartlang-app: URI and we don't know how to map that back to the users local file system so we (the legacy debug adapter in Dart-Code) chooses to download the source from the VM.

It's possible that lookupResolvedUris fixes this, but we only implemented that in the new DAPs (and so far have not migrated webdev to new DAPs...). I can do some testing of this and if lookupResolvedUris fixes it, we can either implement that in the legacy DAP or (ideally) make a webdev DAP in the SDK.

DanTup commented 6 months ago

I did some testing today and confirmed that lookupResolvedPackageUris is mapping org-dartlang-app to file: URIs, so I may be able to fix this in the legacy DAPs (and if we migrate to hew SDK DAPs, that would already be implemented).

I don't know why this only occurs here - maybe the Dart VM is probably not using org-dartlang-app URIs for things outside the lib folder? If so, making webdev match that might also be a fix - but I don't know a) if that's correct or b) if there are other implications of that (I presume there's a reason it's working like this).

bkonyi commented 1 month ago

How much work would this be to look into @DanTup?

DanTup commented 1 month ago

Do you mean how much work to support look lookupResolvedPackageUris in the legacy DAP for webdev?

We previously discussed EOLing that debug adapter because it's wildly out of date and there are almost no users of it. If we think we need to continue supporting it, I think a better route would be to create a new Dart-based DAP for it (possibly in pkg:webdev?). That would be a little more effort in the short-term, but less over a longer period because we wouldn't be developing things twice (or having inconsistent experience between Dart web and debugging other platforms).