DDC with kernel only uses the basename for the library

[jakemac53]

Currently in the webdev vm service proxy we run an eval like this to get the library names for a module:

require('dart_sdk').dart.getModuleLibraries("example/hello_world/main") (this corresponds to an example/hello_world/main.dart file).

Previously, this would have given us a library uri of hello_world/main.dart, but in kernel mode it gives a library name of just main.dart (note that neither include the example top level directory).

This causes issues for the vm service because we report a uri for the root library that doesn't correspond to one on disk. That translates into the source failing to load in the debug pane in devtools.

It happens to work out nicely how it acted before (just trimming the first top level directory), because we only serve top level directories. However it feels weird for ddc to do anything specific to webdev/build_runner as well.

[jakemac53]

cc @vsmenon @alan-knight

[vsmenon]

Note, I think DDK will qualify by parent directory if there is a conflict:

• a/foo.dart -> a__foo
• b/foo.dart -> b__foo
• b/bar.dart -> bar

One of the goals here was smaller names / smaller code (dir structure is deep in internal code).

We could implement the old style - but we might need to add back library_root (i.e., qualify name relative to this root) if we took that out.

Do we need to revisit in D24?

[jakemac53]

Yes I think we need to revisit it - otherwise trying to map these names back to the original dart files is going to be pretty difficult/hacky. How does the existing logic work given modular compilation? We don't expose to it what the other available files are and they could be in other modules.

Library root would work well for us and allow us to control the naming a bit which would be nice, so we don't have to muck with it after the fact (we would always pass the top level dir as the library root, which is the directory that webdev serves).

Alternatively the relative path from the multi-root as we provide it would be fine, and we could strip the top level dir when we report the name. For instance we pass uris like this org-dartlang-app:///web/main.dart. In that case I would expect web/main.dart as the name of the library.

[jakemac53]

See the trackLibraries call in a typical main.dart:

  dart.trackLibraries("web/main", {
    "main.dart": main$2
  }, '{"version":3,"sourceRoot":"","sources":["org-dartlang-app:///web/main.dart"],"names":[],"mappings":";;;;;;;;;;;;AAWI;MACF,MAAM;MACN,4BAAuB;MACvB;MACA;IACF","file":"main.ddc.js"}');

I think we pretty much just need to change the library name there to be the full path.

[jakemac53]

I also noticed that the library names are definitely duplicated today when you have multiple modules under web with the same file names, calls to require('dart_sdk').dart.getLibraries() will end up with duplicate main.dart entries.