Modules/1.1.1
STATUS: APPROVED BY DISCUSSION PARTICIPANTS
- Implementations
- [[Implementations/Yabble|]], [[Implementations/CouchDB|]], [[Implementations/Narwhal|]] (0.2), [[Implementations/Wakanda|]], [[Implementations/TeaJS|]], [[Implementations/CommonScript|]], [[Implementations/PINF|]], [[Implementations/SeaJS|]], [[Implementations/AvocadoDB|]], [[Implementations/sorrow.js|]], [[Implementations/lithe|]]
Show of hands: Mikeal, Gozala, Zach Carter, Hannesw, Tobie, Ondřej Žára, Charles Jolley, KrisKowal, Chris Zumbrunn, Gmsox
This specification addresses how modules should be written in order to be interoperable among a class of module systems that can be both client and server side, secure or insecure, implemented today or supported by future systems with syntax extensions. These modules are offered privacy of their top scope, facility for importing singleton objects from other modules, and exporting their own API. By implication, this specification defines the minimum features that a module system must provide in order to support interoperable modules.
Contents
Contract
Require
- require is a Function
- The "require" function accepts a module identifier.
- "require" returns the exported API of the foreign module.
- If there is a dependency cycle, the foreign module may not have finished executing at the time it is required by one of its transitive dependencies; in this case, the object returned by "require" must contain at least the exports that the foreign module has prepared before the call to require that led to the current module's execution.
- If the requested module cannot be returned, "require" must throw an error.
- The "require" function may have a "main" property.
- This attribute, when feasible, should be read-only, don't delete.
- The "main" property must either be undefined or be identical to the "module" object in the context of one loaded module.
- The "require" function may have a "paths" attribute, that is a prioritized Array of path Strings, from high to low, of paths to top-level module directories.
- The "paths" property must not exist in "sandbox" (a secured module system).
- The "paths" attribute must be referentially identical in all modules.
- Replacing the "paths" object with an alternate object may have no effect.
- If the "paths" attribute exists, in-place modification of the contents of "paths" must be reflected by corresponding module search behavior.
- If the "paths" attribute exists, it may not be an exhaustive list of search paths, as the loader may internally look in other locations before or after the mentioned paths.
- If the "paths" attribute exists, it is the loader's prorogative to resolve, normalize, or canonicalize the paths provided.
Module Context
- In a module, there is a free variable "require", which conforms to the above definiton.
- In a module, there is a free variable called "exports", that is an object that the module may add its API to as it executes.
- modules must use the "exports" object as the only means of exporting.
- In a module, there must be a free variable "module", that is an Object.
- The "module" object must have a "id" property that is the top-level "id" of the module. The "id" property must be such that require(module.id) will return the exports object from which the module.id originated. (That is to say module.id can be passed to another module, and requiring that must return the original module). When feasible this property should be read-only, don't delete.
- The "module" object may have a "uri" String that is the fully-qualified URI to the resource from which the module was created. The "uri" property must not exist in a sandbox.
Module Identifiers
- A module identifier is a String of "terms" delimited by forward slashes.
- A term must be a camelCase identifier, ".", or "..".
- Module identifiers may not have file-name extensions like ".js".
- Module identifiers may be "relative" or "top-level". A module identifier is "relative" if the first term is "." or "..".
- Top-level identifiers are resolved off the conceptual module name space root.
- Relative identifiers are resolved relative to the identifier of the module in which "require" is written and called.
Unspecified
This specification leaves the following important points of interoperability unspecified:
- Whether modules are stored with a database, file system, or factory functions, or are interchangeable with link libraries.
- Whether a PATH is supported by the module loader for resolving module identifiers.
Unit Tests
Sample Code
- math.js
exports.add = function() { var sum = 0, i = 0, args = arguments, l = args.length; while (i < l) { sum += args[i++]; } return sum; };
- increment.js
var add = require('math').add; exports.increment = function(val) { return add(val, 1); };
- program.js
var inc = require('increment').increment; var a = 1; inc(a); // 2 module.id == "program";
Notes
- Secure Modules
- How Modules relate to global natives like String
- How do you extend native prototypes from a Module?
- Notes on compiling modules for browsers
- On writing modules that also work as <script>s
Related Documents
- Proposal to ECMA TC39: Module System for ES-Harmony
- Presentation to ECMA TC39: Modules
Related Discussion
- RFC require.paths behaviour
- Module meta data Proposal. (resurrection of this discussion)
- require.main === undefined Options
- Modules 1.1 Comments
- Modules/1.1.1 Show of Hands