remove library-root option from DDC and don't generate very long library names

[jmesserly]

We should choose short names for local use, at least (and possibly for export as well), and remove the library-root flag.

A simple heuristic would be to just take the file name without extension, rather than jsLibraryName which is the full export name (includes path).

As a related issue, we should also shorten the library names in the export path. As long as we can see the set of library URIs in a JS module (with its Dart summary), we can choose a short, reasonable looking unique name. That also lets us remove the legacy library-root flag for file URIs.

[jmesserly]

tagging performance because this affects code size and likely JS parse times/memory usage.

[jmesserly]

Ah, this happens because of how we generate ES6 export/import. Currently export/import name must match the local name we're using. That's fixable, but it's also a nice property to have & will look nicest when we've moved over to modules.

So it might be easier to attack the library-root issue directly, and have DDC assign short non-conflicting names for each library in a module. I think this will be easier to implement in DDK, where (I think) we can see which libraries belong to which summaries. I'm not sure if we have that information in Analyzer (without re-parsing the summary or something like that).

[jmesserly]

Yet another way to attack this one is to use library names less often. For classes/top-level functions, we can usually use a local variable instead. That would have a big benefit to code size for some of the code I'm seeing.

[jmesserly]

https://dart-review.googlesource.com/c/sdk/+/42885

[nex3]

Synthesizing/revising my proposal from #27262:

I propose that the exported (and optionally imported as well) name of a given Dart library default to the shortest final sub-path of the library's path that's unique to the module being generated, with the .dart extension removed, converted to an identifier by replacing any non-identifier characters with underscores. For example:

The command-line syntax would be extended to allow inputs of the form path,identifier¹ where path is the path (or ideally URL; see #27266) to the Dart library and identifier is the identifier to export it as. For example:

• If lib/foo.dart has no imports, dartdevc lib/foo.dart -o module.js would generate:

  export const foo = { /* members of lib/foo.dart */ };

• If lib/foo.dart imports lib/src/foo.dart, dartdevc lib/foo.dart -o module.js would generate:

  export const foo = { /* members of lib/foo.dart */ };
  export const src_foo = { /* members of lib/src/foo.dart */ };

• dartdevc lib/foo.g.dart -o module.js would generate:

  export const foo_g = { /* members of lib/foo.g.dart */ };

• dartdevc file1.dart:one file2.dart -o module.js would generate:

  export const one = { /* members of file1.dart */ };
  export const file2 = { /* members of file2.dart */ };

• dartdevc lib/foo.dart:bar lib/bar.dart -o module.js would generate:

  export const bar = { /* members of lib/foo.dart */ };
  export const lib_bar = { /* members of lib/bar.dart */ };

The name for each library would be embedded in the module summary so that downstream invocations of dartdevc would know how to refer to it without needing extra configuration on the user's part.

---

1. I'm using , as a separator here rather than my original proposal of :, both to match the existing --url-mapping flag and because , is much less likely to conflict with URL syntax.

[jmesserly]

The command-line syntax would be extended to allow inputs of the form path,identifier1 where path is the path (or ideally URL; see #27266) to the Dart library and identifier is the identifier to export it as. For example:

I like this idea, but we can't implement a flag right now because there's no place for DDC to save extra info in Analyzer summaries/Kernel IL files. Also DDC consumes summaries that are built by other tools (e.g. Analyzer CLI). I believe this is done to get more build parallelism. But it means we can't transmit any information between separately compiled modules. (Most modular compilers do not have this restriction, and it would be nice to see it lifted for DDC.)

For our debugger UI, we already emit a URI->library object map, so it shouldn't be too difficult to provide an API for importing via Dart library URI. That would provide a reliable way of importing libraries from JS without relying on the compiler's library naming scheme.

[nex3]

I like this idea, but we can't implement a flag right now because there's no place for DDC to save extra info in Analyzer summaries/Kernel IL files. Also DDC consumes summaries that are built by other tools (e.g. Analyzer CLI). I believe this is done to get more build parallelism. But it means we can't transmit any information between separately compiled modules. (Most modular compilers do not have this restriction, and it would be nice to see it lifted for DDC.)

Would it still be possible to use my default de-duplication scheme immediately?

For our debugger UI, we already emit a URI->library object map, so it shouldn't be too difficult to provide an API for importing via Dart library URI. That would provide a reliable way of importing libraries from JS without relying on the compiler's library naming scheme.

I'm curious to hear more about this... where does this file go? How would it be used by downstream dartdevc invocations exactly?

[jmesserly]

Would it still be possible to use my default de-duplication scheme immediately?

yes, something similar is implemented in https://dart-review.googlesource.com/c/sdk/+/42885

I'm curious to hear more about this... where does this file go? How would it be used by downstream dartdevc invocations exactly?

It's runtime data. So we could use it to provide a reliable import from JS, for example, by making that mapping the default export:

import fooPkg from 'foo';
let bar = fooPkg['package:foo/bar.dart'];

That isn't implemented yet, currently it relies on string-based global module table, so it looks like:

let fooPkg = dart.getModuleLibraries('foo');
let bar = fooPkg['package:foo/bar.dart'];

[nex3]

Oh, interesting. Not super friendly as far as consuming Dart from JS is concerned, but that does seem like a reasonable stopgap solution until DDC can embed information in the summary.