ServerJS/Modules/Meta

Contract

Module Context

1. In a module, there is a free variable "require", that is a function.
   1. …
   2. …
   3. …
   4. …
   5. The "require" function may have a "main" property that is the top-level "id" of the program.
   6. 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.
      1. The "paths" property must not exist in "sandbox" (a secured module system).
      2. The "paths" attribute must be referentially identical in all modules.
      3. Replacing the "paths" object with an alternate object may have no affect.
      4. If the "paths" attribute exists, in-place modification of the contents of "paths" must be reflected by corresponding module search behavior.
      5. 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.
      6. If the "paths" attribute exists, it is the loader's prorogative to resolve, normalize, or canonicalize the paths provided.
2. In a module, there must be a free variable "module", that is an Object.
   1. The "module" object must have an "id" that is the top-level "id" of the module.
   2. The "module" object may have a "path" String that is the fully-qualified path to the file from which the module was created. The "path" property must not exist in a sandbox.

Discussion

• RFC reqiure.paths behaviour

Show of Hands

1. Do not integrate this amendment into the next version of the SecurableModules specification:
2. Integrate this amendment into the next version of the SecurableModules specification:
   • Hannes Wallnoefer
   • Kris Kowal
   • Tom Robinson
   • Daniel Friesen
   • George Moschovitis