system

# CommonJS Modules ## top-level Verifies that top-level identifiers refer to modules at the top level of a package, even when used from a child level. ## relative Verifies that relative module identifiers find neighboring modules in the module identifier space. ## cyclic Verifies that modules can have cyclic references. ## determinism Verifies that the module loader does not fall back to using relative module identifiers when a top-level module identifier doesn't exist. ## exactExports Verifies that the exports object within a module matches the exports object returned by require. Alternate designs were proposed where the exports as returned by require would be a "defensive" snapshot, preventing lazy definition. ## hasOwnProperty Verifies that "hasOwnProperty" is a valid module identifier, indicating that the implementation considers this special case if using objects as maps. ## method Verifies that the functions exported by a module are not implicitly bound to an object, albeit the exports or the module object. ## nested Verifies that a module burried in a directory tree can be required. ## transitive Verifies that an exported object can be imported and exported from module to module. # CommonJS Modules Amendments ## monkeys Verifies that modules can be modified by other modules. ## return Verifies that a module can replace its exports by returning a defined value. ## module-exports Verifies that a module can replace its exports by assigning directly to `module.exports`. ## missing Verifies that a module will be executed even if it fails to load. The execution will throw an error. ## not-found Verifies that a module will be executed even if it fails to load. The execution will throw an error with a specific message. This test overlaps with `missing` and might be consolidated. ## comments Verifies that a module will be executed even if it has a spurious dependency mentioned in a comment. The commented dependency may fail to load but will not prevent the dependee from executing. ## case-sensitive Verifies that this system does case consistency checks. A module may only be loaded with one case convention, as a slight integrity check to verify that it can be hosted on a case-insensitive file system. It would be better to do integrity checks verifying that module identifiers are always lower-case (per the specification), but this is too strict in practice. ## reexecute This test is not included in the suite because it is a non-normative behavior. Illustrates that the current implementation has an edge case whereby a module can cause itself to be reexecuted for every user. # CommonJS Packages ## named-packages Verifies that named dependencies can be shared if they have a common ancestor. ## named-mappings Verifies that named mappings can be shared if they have a common ancestor. ## load-package Verifies that packages can be loaded asynchronously based on their location relative to the requesting package. As a byproduct, verifies that require.loadPackage and require.async return functioning promises. As a byproduct, also verifies that module exports reassignment works properly. ## load-package-name Verifies that packages can be loaded asynchronously based on their name, in the context of the requesting package. ## named-parent-package Verifies that a dependee package can use the dependent package by its name. ## dev-dependencies Verifies that modules linked in `devDependencies` of `package.json` can be loaded. ## production Verifies that when `package.json` has `production` set, modules linked in `devDependencies` are not loaded. ## identify Verifies that `require.identify(id, require2)` can reverse-lookup the identifier for a module in another package, by its id as known in the other package. ## redirects Verifies that a package can describe redirects from one module identifier to an alternative. ## redirects-package Verifies that a package can describe redirects from one module identifier to an alternative in a dependency package.