Ok sure, while I understand nesting is no longer supported, it could
potentially still make sense in terms of defining the module being an
operation.

Consider as an equivalent to the example the following:

foo.js:
System.set('foo', new Module({
  p: 'value'
}));
System.set('foo/dependency', new Module({
  q: 'dep'
}));

main.js:
System.import('foo');

The question was specifically if foo would be an empty module, or the
defined module in this case. With the current spec it would be an empty
module.

This is fine though, the work around as you say is to use exports for the
exact module name being built. Future build tools would need to take this
into consideration. Glad to have this clarified though.

Guy

On 31 July 2013 04:53, Sam Tobin-Hochstadt <samth at cs.indiana.edu> wrote:

> I think one of us is confused here. How are you importing from
> 'foo.js'? If you're importing from it, expecting that it's the body of
> a module, then you'll get a syntax error -- modules don't nest.
>
> You could configure the loader so that it treats 'foo.js' as
> containing the definition of the 'foo' module plus other modules, in
> which case this works fine but there's no empty module at all.
>
> Sam
>
> On Wed, Jul 31, 2013 at 3:05 AM, Guy Bedford <guybedford at googlemail.com>
> wrote:
> > I'm in the process of matching up an ES6 module loader with AMD support
> to
> > the RequireJS tests, and have a question on concatenated module files.
> >
> > If I have a module, foo.js, which defines its own name and its
> dependencies:
> >
> > foo.js:
> > module 'foo' {
> >   export var p = 'value';
> > }
> > module 'foo/dependency' {
> >   export var q = 'dep';
> > }
> >
> > When loaded, will this ensure that the module value is defined from the
> > module statement taking precedence over the empty module implied by the
> lack
> > of exports?
> >
> > These techniques are used extensively for builds in RequireJS, which I
> think
> > would be very useful in ES6 modules and for the AMD polyfill path.
> >
> > Clarification would be appreciated to know if I'm correct in including
> this.
> >
> > Guy
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130731/68a53a86/attachment.html>

Ok sure, while I understand nesting is no longer supported, it could
potentially still make sense in terms of defining the module being an
operation.

Consider as an equivalent to the example the following:

foo.js:
```js
System.set('foo', new Module({
  p: 'value'
}));
System.set('foo/dependency', new Module({
  q: 'dep'
}));
```

main.js:
```js
System.import('foo');
```

The question was specifically if foo would be an empty module, or the
defined module in this case. With the current spec it would be an empty
module.

This is fine though, the work around as you say is to use exports for the
exact module name being built. Future build tools would need to take this
into consideration. Glad to have this clarified though.