Modules/Loaders

STATUS: PROPOSALS

There are a variety of reasons why it should be possible to create new module systems from within a module system. For one, such a system would make it possible to write test scaffolds for a module, where modules are injected around a module to simulate its interface with the rest of the world. Also, the ability to load a module is a capability (in the object-capability programming sense), but can be made a very safe capability by restricting the loadable modules to a carefully managed branch of a file system, by statically verifying that the content of the module is compliant with the CommonJS module specification, and by otherwise freezing and attenuating all other security hazards. Doing all of these things guarantees that, if you instantiate a module system, the modules therein would only have the ability to perform computation, and manipulate the capabilities you deliberately inject into that system. Another facet of exposing some of the internal mechanisms for finding, evaluating, and loading modules is that these facilities can be used to create more advanced module systems for domain specific languages.

Proposals

• The proposal for modules to ECMA TC39 in January 2009 included a module loader design. The design in practical implementations has drifted and improved since.
• Modules/Loaders/A accompanied the original Modules/SecurableModules proposal, was ignored, and now has become obsolete.
• Modules/Loaders/B