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.
- A module receives a "require" Function. The "require" function may be called with an absolute or relative module identifier. It will receive an object containing the exported API of the foreign module. If there is a dependency cylce, 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" throws an error.
- A module receives an "exports" object, synonymous with "this" in the top scope of the module, that it may add its exported API to as it executes.
- A module receives a "require.env" object that contains objects provided by the module "sandbox" for communication with host environment.
- A module is guaranteed that "var" and "function" declarations are not communicated to other modules.
To be interoperable with secure environments, a module must satisfy the following additional constraints:
- A module must not have any free variables apart from primordials ("Object", "Array", &c), "require", and "exports".
- A module must not tamper with (assign to, or assign to members of) the transitive primordials, or "require" object.
This specification leaves the following important points of interoperability unspecified:
- The domain of module identifiers.
- The contents of the environment, "require.env".
- Whether a PATH is supported by the module loader.