Modules: suggestions from the field

# James Burke (11 years ago)

I have suggested alterations to the modules effort, and an in-progress prototype[1].

It is based on field usage of existing JS module systems, and my work supporting AMD module solutions for the past few years.

There is a document describing what it attempts to fix[2]. The table of contents from that document:

—

This project reuses a lot of thinking that has gone into the ECMAScript 6 modules effort so far, but suggests these changes:

Parse for module instead of import/export
Each module body gets its own unique module object
Use function wrapping for module scope

They are motivated by the following reasons:

import syntax disparity with System.import
Solves the moduleMeta problem
Solves nested modules and allows inlining
Easy for base libraries to opt in to ES modules

It has these tradeoffs:

Cycle support
Export name checking

—

I am willing to talk to TC-39 members in realtime channels (video/in person) that may need more background or might want to discuss further, but I am less likely to discuss it in email threads.

I will likely continue that prototype effort even if the more recently visible issues for modules are solved differently, as the current state of the baseline ES system will still require bootstrap loader scripts. For the bootstrap scripts, I will need some of the concepts in the prototype for the AMD consumers I have traditionally supported.

There is a “story time” document[3] for a narrative around how the prototype relates to smaller ideas around code referencing and reuse.

[1] jrburke/module [2] jrburke/module/blob/master/docs/module-from-es.md [3] jrburke/module/blob/master/docs/story-time.md

James

I have suggested alterations to the modules effort, and an in-progress
prototype[1].

It is based on field usage of existing JS module systems, and my work
supporting AMD module solutions for the past few years.

There is a document describing what it attempts to fix[2]. The table
of contents from that document:

—

This project reuses a lot of thinking that has gone into the
ECMAScript 6 modules effort so far, but suggests these changes:

* Parse for module instead of import/export
* Each module body gets its own unique module object
* Use function wrapping for module scope

They are motivated by the following reasons:

* import syntax disparity with System.import
* Solves the moduleMeta problem
* Solves nested modules and allows inlining
* Easy for base libraries to opt in to ES modules

It has these tradeoffs:

* Cycle support
* Export name checking

—

I am willing to talk to TC-39 members in realtime channels (video/in
person) that may need more background or might want to discuss
further, but I am less likely to discuss it in email threads.

I will likely continue that prototype effort even if the more recently
visible issues for modules are solved differently, as the current
state of the baseline ES system will still require bootstrap loader
scripts. For the bootstrap scripts, I will need some of the concepts
in the prototype for the AMD consumers I have traditionally supported.

There is a “story time” document[3] for a narrative around how the
prototype relates to smaller ideas around code referencing and reuse.

[1] https://github.com/jrburke/module
[2] https://github.com/jrburke/module/blob/master/docs/module-from-es.md
[3] https://github.com/jrburke/module/blob/master/docs/story-time.md

James

# James Burke (11 years ago)

I added a doc about module inlining/nesting, and why it should be supported in a module system. Mentions SPDY/HTTP2, packaged formats, Node’s Browserify, and transpiling:

jrburke/module/blob/master/docs/inlining.md

James

I added a doc about module inlining/nesting, and why it should be
supported in a module system. Mentions SPDY/HTTP2, packaged formats,
Node’s Browserify, and transpiling:

https://github.com/jrburke/module/blob/master/docs/inlining.md

James

On Mon, Jun 16, 2014 at 1:21 PM, James Burke <jrburke at gmail.com> wrote:
> I have suggested alterations to the modules effort, and an in-progress
> prototype[1].
>
> It is based on field usage of existing JS module systems, and my work
> supporting AMD module solutions for the past few years.
>
> There is a document describing what it attempts to fix[2]. The table
> of contents from that document:
>
> —
>
> This project reuses a lot of thinking that has gone into the
> ECMAScript 6 modules effort so far, but suggests these changes:
>
> * Parse for module instead of import/export
> * Each module body gets its own unique module object
> * Use function wrapping for module scope
>
> They are motivated by the following reasons:
>
> * import syntax disparity with System.import
> * Solves the moduleMeta problem
> * Solves nested modules and allows inlining
> * Easy for base libraries to opt in to ES modules
>
> It has these tradeoffs:
>
> * Cycle support
> * Export name checking
>
> —
>
> I am willing to talk to TC-39 members in realtime channels (video/in
> person) that may need more background or might want to discuss
> further, but I am less likely to discuss it in email threads.
>
> I will likely continue that prototype effort even if the more recently
> visible issues for modules are solved differently, as the current
> state of the baseline ES system will still require bootstrap loader
> scripts. For the bootstrap scripts, I will need some of the concepts
> in the prototype for the AMD consumers I have traditionally supported.
>
> There is a “story time” document[3] for a narrative around how the
> prototype relates to smaller ideas around code referencing and reuse.
>
> [1] https://github.com/jrburke/module
> [2] https://github.com/jrburke/module/blob/master/docs/module-from-es.md
> [3] https://github.com/jrburke/module/blob/master/docs/story-time.md
>
> James