caridy/for-review.md Secret

## for-review.md

      
    Raw
  

              for-review.md
            
          
    1. ModuleImport syntax <ImportDeclaration>

Should we kill the ModuleImport syntax?
module foo from "foo"; // drop this
import bar from "bar";
Pros:

module keyword is very confusing (e.g.: is this a definition of a new module? what is the from part?, etc.)
Removing ModuleImport will simplify the import/export syntax.

Cons:

without a way to access the module object, it is difficult to deal with modules with many exports (e.g.: underscore), but we could fix this by using a reflective API to access imported modules

Resolution:

let's kill it.
let's use an imperative syntax to access the module object (see 3rd bullet for more details)
@ericf will open the tickets to update the specs

(https://people.mozilla.org/~jorendorff/es6-draft.html#sec-imports)
2. What's the execution context for a module?

// this !== realm.global?
// this !== Reflect.global?
// this === <ModuleMeta>?
// this === Object.create(null) per module?
export function foo() {};

// potential confusing side effect: `this.exports.foo()`???
Pros:

this.something will not define global variables
this.something will not be shared between modules

Cons:

how to access realm.global from within the module?

Resolution:

let's change it.
Reflect.global will be the way to access the global scope
this === Object.create(null) can be created by loader, this object will provide this.module amoung other members. (see 3rd bullet for more details)
@ericf will open the tickets to update the specs

3. lazy loading modules

3.1 module = moduleMeta

updated: this proposal was dropped in favor of 3.2
module keyword points to the module meta (a la nodejs)
index.html
<script>
System.import('app');
</script>
app.js
export function init() {
  // critical initialization steps
  // ...
  module.import('./lazy-mod').then(m => { 
    // then, do less important things...
  });
};
In this example, module.import() is sugar to normalize the module name based on the host module metadata.
Pros:

module.import() is similar to System.import()
it is ergonomic
prevents loader leaks since loader instance is not accesible from the module code
module.name and module.address are available

Cons:

metamodule api has to be defined (whitelist/getters for loader records)
import method have to be attached to the metamodule per module (since it wraps the normalization for relative modules).
module.exports, a la nodejs, but immutable. Is this even an issue?
module happens thru some magic under the hood (nodejs does this by executing a function and passing arguments to it)

Resolution:

introducing a magical module variable is not desirable, instead we will stick to this, which is described in 3.2.

3.2 @wycats proposal this = moduleMeta

Similar to 3.1 but using this instead of module.
index.html
<script>
System.import('app');
</script>
app.js
let moduleMeta = this; // or Reflect.Loader.getModuleMeta(this);
export function init() {
  // critical initialization steps
  moduleMeta.import('./lazy-mod').then(m => {
    // then, do less important things...
  };
};
Pros:

prevents loader leaks since no loader is accesible from the module code
this.name and this.address available after normalization and location
seems to be easy to implement (no many changes in the specs are needed)

Cons:

this.import() might throw people off by thinking that this === System
metamodule api has to be defined (whitelist/getters for loader records)
import method have to be attached to the metamodule per module (since it wraps the normalization for relative modules).
potentially confusion with: this.import() vs import foo from "foo";
this might be confusing. footgun, imagine people trying this.import() within a function.

Resolution:

this is some sort of meta module (we need a better term) that provide access to some functionalities bound to the host module, like this.import(), this.get(), etc.
this.module provides access to the exports
Reflect.Loader.getModuleMeta(this) is unnecessary.
@ericf will open the tickets to update the specs

(https://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-scriptevaluation)

  
## on-agreement.md

      
    Raw
  

              on-agreement.md
            
          
    1. bug:2601 System.import() promise cache

System.import('foo');
System.import('foo');


should the second import() return a promise bound to the previous call?

2. bug:2755, bug:2795 linkSet()

TBD (@guybedford will provide more information)
3. bug:2659 System.import() normalization


it should normalize the name of the module to match the declarative syntax