Inline ES Modules

[Peter van der Zee]

I actually quite like the idea.

- Extend the import syntax to allow an identifier instead of a string.
Such identifier must be match the name of a module declaration the
same file (they are hoisted and a syntax error if not
present/something else).
- Module declaration names are abstracts since they are "exposed" in
the scope through an import.
- Module declarations only allowed on the global level (like
import/export declarations)
- Maybe in the future modules could refer to their name identifier to
access meta data.
- Module bodies are for all intentions and purposes treated as if they
were independent js module files
- Module identifiers are hoisted

Bonus points for making the end token easier to scan for
(realistically speaking I'm pretty sure a regular block is preferred).
This could help browsers parse large bundle files by fast scanning
past module blocks.

```
import foo from bar;
module bar {#
  log('I'm a module!');
#}
```

The downside to inline modules is that I'm not sure whether this has
more real use beyond webpack/metro/rollup/etc bundlers that put all
modules in one bundle file. However, that might still help js envs in
some way.

This kind of thing wouldn't need to be a huge tax on the spec by
reusing existing semantics.

- peter

On Mon, Jun 18, 2018 at 11:10 PM, Darien Valentine
<valentinium at gmail.com> wrote:
> ```
> import getPersonType from 'data:text/javascript,\
>   export default function getPersonType(person) {\
>     switch (person) {\
>       case \'Teacher\': return \'A teacher\';\
>       case \'Director\': return \'A director\';\
>     }\
>   }';
> ```
>
> okay, not a serious suggestion, but it does technically work :)
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>