ES6 modules don't work in DDC, remove library-root, module-root

[jmesserly]

There are two problems:

DDC imports with unqualified names like "foo" instead of relative paths like "./foo". While this is supported by existing JS module systems, it is not supported by built-in ES6 module loaders. We also need to remove module-root because it's not the right UX. Instead we should allow the user to provide the JS import path along with a summary for that module, with some sort of default behavior (probably flat modules: "./module_name"). We'll also need a way to provide the SDK import path.

The other problem is with library names. They are exports of temporary identifiers, which can be renamed, breaking the module's ABI. It works in existing JS module systems, because DDC desugars ES6 export into a renamed local and a non-renamed export. We should be able to fix this by using export as. I think import already has a way to handle TemporaryId names and generate as when needed.

(Original proposal/discussion here: #27262)

[nex3]

Synthesizing/revising my proposal from the original thread:

I propose that the --summary flag be extended to allow the form --summary=path,import¹ where path is the path (or ideally URL; see #27266) to the summary and import is the URL to use to import it. The import URL would default to the relative URL to the summary file from the output file, without the summary extension² and with a ./ prefix³. So for example:

• dartdevc app.dart -o app.js --summary build/lib.sum would generate:

  import { /* ... */ } from './lib';

• dartdevc app.dart -o app.js --summary build/lib.sum,../shared/lib would generate:

  import { /* ... */ } from '../shared/lib';

• dartdevc app.dart -o app.js --summary build/lib.sum,http://localhost:1234/lib would generate:

  import { /* ... */ } from 'http://localhost:1234/lib';

I also propose an --sdk-import flag that defines the URL from which the SDK module is imported. This would default to dart_sdk, as it does today.

---

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.

2. My original proposal just used the basename of the file because it was derived from a proposal about the old custom module loader, but I think in an ES6-first world relative URLs make more sense.

3. I don't think this prefix is meaningful for browsers, but for Node.js it's used to signal a relative import (as opposed to a load-path import).

[jmesserly]

import { /* ... */ } from 'lib';

did you mean "./lib" here, because of the rule "with a ./ prefix"

3. I don't think this prefix is meaningful for browsers, but for Node.js it's used to signal a relative import (as opposed to a load-path import).

Yeah, I need to double check the status of this in browsers. At one point it seemed like explicit relative path syntax was required. In any case, I agree with your point in 3--since browsers only support relative paths, it's nice to use that across all of our module formats for consistency.

[nex3]

did you mean "./lib" here, because of the rule "with a ./ prefix"

Yep, fixed, good catch.

[jmesserly]

https://dart-review.googlesource.com/c/sdk/+/42892 addresses the library name export bug. Need another CL for the module-root issue.

[jmesserly]

the export name issue is fixed in 1b9b345 ... library-root CL is under development, and module-root still needs to be looked at.

[jmesserly]

progress on deprecating module-root: https://dart-review.googlesource.com/c/sdk/+/64823

It appears the option of passing the import name was already implemented (though it needed some refactoring). For example -s summary_path=js_import_path. I added an option to specify the output module name from the original proposal (used by some module formats like AMD and DDC's legacy format, ES6 and CommonJS do not need it).

Next up is bringing these new options over to dartdevk (it has never supported module-root or library-root, but it also does not support the correct way of providing import name via --summary or the new --module-name option).