You can develop your own plugins for the mocks server to provide more interfaces,
add more ways of defining fixtures or behaviors (not yet available), etc.
It is recommended that plugins are published with the "mocks-server-plugin-[name]" name format in order to facilitate the search. Plugins should also contain the "mocks-server-plugin" tag in the
Plugins should contain three main methods, which will receive the instance of the Mocks Server core. Please read the programmatic usage chapter to know how to interact with the core.
This method will be called for registering the plugin during the Mocks Server initialization, before
options have been initialized.
Here you should register your own custom
options using the
core.addCustomSetting method, register your own custom express routers using the
core.addCustomRouter method, etc.
You should never access here to the
core.settings methods, are they are not still ready in this phase, which was defined with the intention of letting the plugins to add their own settings.
If you define your plugin as a Class, the
constructorwill be equivalent to defining a
registermethod. If you define your plugin as a function, it will be called during the plugins registration, so you could also omit the
This method will be called when mocks server settings are ready. Here you already can access to the
core.settings to get the user options, and act in consequence. Here you should also add your listeners to the core events, such as
When this method is called, the mocks server is already started and listening to requests, and the files watcher is observing for changes too.
Here you have an example of how a plugin is defined. Consult the Mocks Server programmatic usage chapter for further info:
The methods can be defined in a plain
object, as methods of a
Class or even using a
function returning an object containing them.
Next examples show how each format should be defined: