Modules

STATUS: 1.1 RATIFIED

Contents 1 Modules 1.1 Specifications 1.2 Proposals 1.3 Prior Art 1.4 Related Discussions

Modules

To date, client side JavaScript has generally been able to get away with something as simple as the <script> tag and no standard way to do namespaces. On the server, it's a bit different because you're more likely to use more libraries and you can potentially load up a lot of code. Having a basic system for loading code and encouraging the use of namespaces to avoid unintentional interference will underlie everything else.

Specifications

• 1.0
• 1.1 (1.0 + Module Meta-object Amendment).
• 1.1.1 relaxes details for "main" and enumerability requirements.
  • version 1.1.1 will need spec tweaks and more work: there has been discussion/argument over the behaviour and formation of module.id, one side going for invariance based on path relative to search paths, the other going for absolute file path, since the top level id is dependent on the require.paths at the time of module load. There is also discussion about what we should and shouldn't allow as an argument to require, particularly about camelCase (which not many platforms mandate) and about file extensions.

Proposals

Several proposals were made. There was convergence toward the Securable Modules proposal, with several implementations passing the unit tests.

1. Global File Loading
2. Global Object Loading
3. Pythonic Modules
4. Securable Modules
5. Declarative Modules proposal, introducing readable module definition format suitable for both server and browser.

There are also proposals for amendments and supplements to these proposals:

1. Modules/Meta ratified and incorporated into Modules/1.1.
2. Modules/Loaders for module loader specification proposals
3. Modules/Transport for module transport format proposals (for a module format suitable for browser script injection)
4. Modules/SetExports function for exporting something other than a plain object.
5. Modules/Async/A proposes async loading.
6. Modules/Metadata proposes JSON metadata.

We need proposals for:

1. A module-relative "resource" object, like module.resource(path).open(…).
2. To fix the module identifier domain. The current specification restricts module identifiers to camelCase delimited by slashes, but this is hazardous in case-insensitve stores, and not restricted in practice.
3. A page for discussing a system for injecting free variables from the exports of a foreign module
4. module.setExports(exports) exports Object

Prior Art

• Spidermonkey (and Jaxer) and Rhino offer a load function, but does not have any specific pattern for namespacing.
• Dojo has a complete incremental loading facility in the form of dojo.require and a standard mechanism for declaring modules. dojo.require ensures that the module is loaded only once. It also manages dependecies between modules.
• The Jack project implements a simple "require" system.
• Persevere uses "require" (similar to Jack) for module loading.
• RingoJS implements a module system with per-module scopes and import, include and require functions.
• jslibs bootstrapping jshost provides only basic code and loading module support, direct from file and either into the global namespace or a chosen namespace http://code.google.com/p/jslibs/wiki/jshost
• Advanced JavaScript Importing & Loading Extension is the browser-independent extension that provides Javascript with namespace and dynamic script loading support ( http://ajile.iskitz.com/ )
• modulesjs an XHR JS module loader provides module loading, singleton modules ( http://modulesjs.com/ )
• Synchronet provides a global load() method which allows a specified scope/sandbox object, passing arguments, and background/concurrent execution: http://synchro.net/docs/jsobjs.html#global
• Ejscript has a loadable module mechanism based on language extensions "module" and "use module" definitions. Modules can have scope, dependencies, incremental loading and optional backing native code.
• Torino implements a C-style "#include" preprocessor which is intended to provide a low-level loading mechanism on top of which more sophisticated module management schemes can be implemented in JavaScript.
• Eclipse E4 is doing work using Rhino to support writing modular JavaScript bundles that can interoperate cleanly with the OSGi modularity layer used by Java plugins in the platform.

Related Discussions

• a module system (difficult to agree)
• Concerns about the proposed module system(s)
• do we need a Module object instead of require() function?
• Are we agreed on require, in general?
• SecurableModules question
• Do you think require() should be implemented in JS?
• Securable Modules show of hands
• Secureable Modules: "exports" vs "this"
• SecurableModules: Namespacing, version numbers
• Global Free Variable
• Modules 1.2 Agenda