Configurable Module Loader actions
Current Behavior
The module loading actions have to be defined in blacklight-core.
New Behavior
Allow individual modules a mechanism for plugging in to the module loading process. This will require some sort of module pre processing to identify ones that care about module loading.
Implementation
Any module can define that it is interested in the module loading processing by creating a file called module-loader.js
under apps
.
- apps
- module-loader.js
This JS file is expected to export an Array of Object, with each Object providing the following properties:
-
pattern (String) : Required. This is that pattern that will be matched against files / directories under the
/apps
directory for each module -
process (Function) : Required. The function that will be run for each module that matches the given
pattern
. Cannot be asynchronous. Function definition must match the following-
process(site, module, path)
-
- site (String) : The site id the matching module belongs to
- module (String) : The module id of the matching module
-
path (String) : The full path to the file or directory that matched the
pattern
-
-
(Any) : Any truthy returned value will be stored in the global BL object. See
globalProperty
for further details.
-
(Any) : Any truthy returned value will be stored in the global BL object. See
-
-
-
globalProperty (String) : Required. The key where the results of the
process
function should be stored for each module. Truthy values returned from theprocess
function will be stored in global.bl.globalProperty
.site
.module
. IfglobalProperty
conflicts with an already existing property an Error will be thrown.
Any module defined module-loaders will be run after the default internal module loader actions.
The current GraphQL and Queue loading should be moved out to separate modules: blacklight.graphql and blacklight.queues, respectively.