Generic logging utility focused around a plugin-architecture to be used in projects and APIs.
- Plugin architecture allows it to be hooked up to external logging services, databases, files, etc
- Plugin can provide optional config (with sane defaults)
- User can overwrite config options
- Plugins receive a
sender
identifier object to point to code paths, plugins, functions, etc
npm install @expressivejs/logger
const logger = require('@expressivejs/logger')
logger.load([ 'examplePlugin' ])
// Somewhere else in project
const logAPI = logger.API()
logAPI.log('I am Logging')
$ I am a Logging
module.exports = {
extends: ['log'],
init: function(config) {
// Every logger must impement an init function.
},
log: function(sender, message) {
if (sender.name)
console.log(`[${sender.name} in ${sender.type}] ${message}`)
else
console.log(`[${sender.type}] ${message}`)
}
}
const exampleUserConfig = {
examplePlugin: {
someProp: true,
},
}
logger.load([ 'examplePlugin' ], exampleUserConfig)
Uses path.resolve()
behind the scenes.
logger.load([ 'examplePlugin' ], null, './loggers')
module.exports = {
someProp: false,
otherProp: true,
}
{ someProp: true, otherProp: true }
Given the above examples, a Plugin provides default config options - however, the user overwrites props provided to exampleUserConfig
.
- In this case,
someProp
is definedfalse
by the plugin - The user config (
exampleUserConfig
) says they wantsomeProp
to betrue
- Other default config options defined by the Plugin are untouched.
Sender can be an object if you require more properties or string. If Sender is a string, an additional param can be used for more information.
const logAPI = logger.API('someModule')
logAPI.log('I am a Logging')
$ [someModule] I am a Logging
const logAPI = logger.API('someModule', 'someFunction')
logAPI.log('I am a Logging')
$ [someFunction in someModule] I am a Logging
const logAPI = logger.API({ functionName: 'someFunction', line: 11 })
logAPI.log('I am a Logging')