Modules: suggestions from the field

[James Burke]

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