Initial --modules=es6 support

lib/src/codegen/module_builder.dart

+// Copyright (c) 2015, the Dart project authors.  Please see the AUTHORS file
+// for details. All rights reserved. Use of this source code is governed by a
+// BSD-style license that can be found in the LICENSE file.
+
+library dev_compiler.src.codegen.js_codegen;

[Jennifer Messerly, 2016/01/22 18:29:01]

fix library name here?

BTW, I heard we can delete library names now, so I may go through en masse and
delete :D

[ochafik, 2016/01/23 12:24:17]

Done.

+
+import '../js/js_ast.dart' as JS;
+import '../js/js_ast.dart' show js;
+import '../options.dart' show ModuleFormat;
+
+abstract class ModuleBuilder {

[Jennifer Messerly, 2016/01/22 18:29:01]

Perhaps add a doc comment to this?

[ochafik, 2016/01/23 12:24:17]

Done.

+  final String _jsPath;
+  final String _jsModuleValue;
+  final JS.Identifier _exportsVar;
+  final List<String> _exports = <String>[];
+  final List<_ModuleImport> _imports = <_ModuleImport>[];
+
+  ModuleBuilder._(this._jsPath, this._jsModuleValue, this._exportsVar);
+
+  factory ModuleBuilder(String jsPath, String _jsModuleValue,
+      JS.Identifier _exportsVar, ModuleFormat format) {
+    switch (format) {
+      case ModuleFormat.dart:
+        return new DartModuleBuilder(jsPath, _jsModuleValue, _exportsVar);

[Jennifer Messerly, 2016/01/22 18:29:01]

I wonder if we could factor this so given an enum value, we can just look up a
method to construct it? I guess without constructor tear offs it's a bit
awkward.

[ochafik, 2016/01/23 12:24:17]

Yes, I did that in the first version
(https://codereview.chromium.org/1612083002/patch/1/10002), but the tearoffs
were driving the formatter (and analyzer) crazy. Also, it would require some
cumbersome typedef to make this typesafe...

+      case ModuleFormat.es6:
+        return new ES6ModuleBuilder(jsPath, _jsModuleValue, _exportsVar);
+      default:

[Jennifer Messerly, 2016/01/22 18:29:01]

I think if you leave off "default", we'll give a warning from Analyzer if we
forget a case.

(static failure being preferable to runtime failure, IMO)

[ochafik, 2016/01/23 12:24:17]

Ah, sweet!

+        throw new ArgumentError("Unsupported format: $format");
+    }
+  }
+
+  void addExport(String name) {
+    _exports.add(name);
+  }
+
+  void addImport(String name, JS.Identifier libVar, {bool isLazy: false}) {
+    _imports.add(new _ModuleImport(name, libVar, isLazy));
+  }
+
+  List<JS.ModuleItem> build(List<JS.Statement> moduleItems);
+}
+
+class _ModuleImport {
+  final String name;
+  final JS.Identifier libVar;
+  final bool isLazy;

[Jennifer Messerly, 2016/01/22 18:29:01]

Maybe we should document that this field is only for legacy Dart format.
Feel free to add something like

// TODO(jmesserly): remove this, it's historical and we shouldn't need it even
in our legacy module format.

[ochafik, 2016/01/23 12:24:17]

Not sure we can remove it, if only for Closure, added this todo:

  // TODO(jmesserly): Assess whether we can remove this (we shouldn't need it
  // even in our legacy module format, but it might still be useful for Closure
  // with ES6 modules).

+  _ModuleImport(this.name, this.libVar, this.isLazy);
+}
+
+/// Generates modules for with DDC's `dart_library.js` loading mechanism.
+class DartModuleBuilder extends ModuleBuilder {

[Jennifer Messerly, 2016/01/22 18:29:01]

Rename to LegacyModuleBuilder?

[ochafik, 2016/01/23 12:24:17]

Done.

+  DartModuleBuilder(jsPath, _jsModuleValue, _exportsVar)
+      : super._(jsPath, _jsModuleValue, _exportsVar);
+
+  List<JS.ModuleItem> build(List<JS.Statement> moduleItems) {
+    // TODO(jmesserly): it would be great to run the renamer on the body,
+    // then figure out if we really need each of these parameters.
+    // See ES6 modules: https://github.com/dart-lang/dev_compiler/issues/34
+    var params = [_exportsVar];
+    var lazyParams = [];
+
+    var imports = <JS.Expression>[];
+    var lazyImports = <JS.Expression>[];
+    var moduleStatements = <JS.Statement>[];
+
+    for (var i in _imports) {
+      (i.isLazy ? lazyImports : imports).add(js.string(i.name, "'"));
+      (i.isLazy ? lazyParams : params).add(i.libVar);
+    }
+    params.addAll(lazyParams);
+
+    moduleStatements.addAll(_flattenBlocks(moduleItems));
+
+    if (_exports.isNotEmpty) {
+      moduleStatements.add(js.comment('Exports:'));
+      // TODO(jmesserly): make these immutable in JS?
+      for (var name in _exports) {
+        moduleStatements
+            .add(js.statement('#.# = #;', [_exportsVar, name, name]));
+      }
+    }
+
+    var module =
+        js.call("function(#) { 'use strict'; #; }", [params, moduleStatements]);
+
+    var moduleDef = js.statement("dart_library.library(#, #, #, #, #)", [
+      js.string(_jsPath, "'"),
+      _jsModuleValue ?? new JS.LiteralNull(),
+      js.commentExpression(
+          "Imports", new JS.ArrayInitializer(imports, multiline: true)),
+      js.commentExpression("Lazy imports",
+          new JS.ArrayInitializer(lazyImports, multiline: true)),
+      module
+    ]);
+    return <JS.ModuleItem>[moduleDef];
+  }
+}
+
+/// Generates ES6 modules.
+///
+/// TODO(ochafik): Break strong dep cycles to accommodate the Closure Compiler.

[Jennifer Messerly, 2016/01/22 18:29:01]

trivial style nit, TODO should not be in a doc comment. So two-slashes.

Maybe it's not worth going into now, but at some point we should discuss the
Closure Compiler issue in more detail? We may need a separate module format for
it, depending on what compromises to readability (vs hand written ES6 code) are
necessary.

I definitely hope we can use the ES6 module format as our primary output.

[ochafik, 2016/01/23 12:24:17]

Absolutely! I think the only diff between ES6ModuleBuilder and
ClosureModuleBuilder will be special handling of lazy imports. I'll start
experimenting / will have more material to discuss as soon as this goes in :-)

+class ES6ModuleBuilder extends ModuleBuilder {
+  ES6ModuleBuilder(jsPath, _jsModuleValue, _exportsVar)
+      : super._(jsPath, _jsModuleValue, _exportsVar);
+
+  List<JS.ModuleItem> build(List<JS.Statement> moduleItems) {
+    // TODO(jmesserly): it would be great to run the renamer on the body,

[Jennifer Messerly, 2016/01/22 18:29:01]

This TODO should move down to the `for (var i in _imports) {` block?

[ochafik, 2016/01/23 12:24:17]

Done.

+    // then figure out if we really need each of these parameters.
+    // See ES6 modules: https://github.com/dart-lang/dev_compiler/issues/34
+    var moduleStatements = <JS.ModuleItem>[];
+
+    moduleStatements.add(js.statement("'use strict';"));

[Jennifer Messerly, 2016/01/22 18:29:01]

"use strict" is not needed in ES6 modules:
http://www.ecma-international.org/ecma-262/6.0/#sec-strict-mode-code

[ochafik, 2016/01/23 12:24:17]

The power of specs! Thanks!

+    // Lazy declarations may reference exports.
+    moduleStatements.add(js.statement("const # = {};", [_exportsVar]));
+
+    for (var i in _imports) {
+      // TODO(ochafik): laziness, late binding, etc, to support Closure...

[Jennifer Messerly, 2016/01/22 18:29:01]

well I hope we don't need lazy imports, because no such concept exists in ES6 :)

To be honest, I don't think it really does anything functional in the current
module system. (It's just an assertion, basically, to catch if the compiler
messed up its dependency order.)

[ochafik, 2016/01/23 12:24:17]

So, I think we'll need some combination of lazy classes, lazy imports, or
breaking each class out to its own module: non-lazy classes need their parent to
be defined when their declaration is evaluated, and references from their bodies
may create import cycles.

I think the runtime dependency order largely depends on which files are imported
first, which is partly out of the compiler's control.

I strongly hope I'm wrong here, can't wait to chat more about this :-)

+      moduleStatements.add(new JS.ImportDeclaration(
+          defaultBinding: i.libVar, from: js.string(i.name)));
+    }
+
+    moduleStatements.addAll(_flattenBlocks(moduleItems));
+
+    if (_exports.isNotEmpty) {
+      moduleStatements.add(js.comment('Exports:'));
+      // TODO(jmesserly): make these immutable in JS?
+      for (var name in _exports) {
+        moduleStatements
+            .add(js.statement('#.# = #;', [_exportsVar, name, name]));
+      }
+      moduleStatements
+          .add(new JS.ExportDeclaration(_exportsVar, isDefault: true));
+    }
+    // TODO(ochafik): What to do of _jsModuleValue?
+    return moduleStatements;
+  }
+}
+
+Iterable<JS.ModuleItem> _flattenBlocks(List<JS.ModuleItem> stats) =>

[Jennifer Messerly, 2016/01/22 18:29:01]

BTW, I wonder if we should add something like this to JS.Block, since it's come
up as useful in a few places?

[ochafik, 2016/01/23 12:24:17]

On second thought, I think this is wrong *in general* (breaks block scoping),
although desirable in the special case of module building (left a TODO, will
address in the backend CL).

+    stats.expand((item) => item is JS.Block ? item.statements : [item]);