STATUS: 1.1 RATIFIED
- 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.
Several proposals were made. There was convergence toward the Securable Modules proposal, with several implementations passing the unit tests.
- Global File Loading
- Global Object Loading
- Pythonic Modules
- Securable Modules
- 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:
- Modules/Meta ratified and incorporated into Modules/1.1.
- Modules/Loaders for module loader specification proposals
- Modules/Transport for module transport format proposals (for a module format suitable for browser script injection)
- Modules/SetExports function for exporting something other than a plain object.
- Modules/Async/A proposes async loading.
- Modules/Metadata proposes JSON metadata.
- Modules/Resources proposes module-relative resource access.
We need proposals for:
- A module-relative "resource" object, like
- 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.
- A page for discussing a system for injecting free variables from the exports of a foreign module
module.setExports(exports) exports Object
- 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
- 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.
- 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