Logging package for my projects
Go to file
2024-10-08 22:32:09 +03:00
.yarn/releases Updating dependencies 2024-10-08 22:30:12 +03:00
scripts parallel esm/cjs builds 2023-04-12 21:34:40 +03:00
src Linter pass + fix logger sometimes not pruning old files 2024-10-08 22:32:09 +03:00
test v2.3.4 2023-06-15 13:13:46 +03:00
.eslintrc.json Updating dependencies 2024-10-08 22:30:12 +03:00
.gitignore Updating dependencies 2024-10-08 22:30:12 +03:00
.yarnrc.yml Updating dependencies 2024-10-08 22:30:12 +03:00
eslint.config.mjs Updating dependencies 2024-10-08 22:30:12 +03:00
index.ts export webhook client options 2023-12-08 14:33:51 +02:00
package.json Updating dependencies 2024-10-08 22:30:12 +03:00
README.md v2.3.4 2023-06-15 13:13:46 +03:00
tsconfig.cjs.json parallel esm/cjs builds 2023-04-12 21:34:40 +03:00
tsconfig.json parallel esm/cjs builds 2023-04-12 21:34:40 +03:00
yarn.lock Updating dependencies 2024-10-08 22:30:12 +03:00

Navy's logger

Simple logger I wrote to have a unified system for logging throughout my projects.

Features

Split into Master and Client for logging between processes, where master resides on the master process and the clients on the spawned processes.
Should be fairly trivial to modify it to work across nodes with websockets or some other IPC protocol.

Note
When logging from a child process, the master logger expects the child process to be be in a wrapper containing at the very least an ID property to work properly (used for identifying which child the message came from).
Notably the logger will work with just a raw child process object though, it will lack the identifier.

The child processes are expected to be attached with the attach() method found in the master logger. This will attatch a listener for the 'message' event.

Logger Options

{ 
    //////// SHARED BETWEEN CLIENT & MASTER
    guard: '_logger', // Message guard, e.g this property has to be true in the IPC message for the logger to read it
    loglevel: false, // On the master logger this determines whether the output is written to console (i.e. will always be written to file), on the client this determines whether it is sent to the master at all
    customTypes: [], // Log types, defaults are 'error', 'warn', 'info', 'debug', 'status'. Each one of these has an associated shorthand function, the custom ones will receive one too, e.g. adding 'access' to the custom types will add a logger.access() function
    logLevelMapping: {
        debug: 0,
        info: 1,
        status: 2,
        warn: 3,
        error: 4
    }
    
    /////// MASTER EXCLUSIVE
    customStreams: [], // File streams, by default there are streams for error and default
    customTypeMapping: {}, // This maps a type to a stream, e.g. adding "warn": "error" will pipe any warnings to the error log file
    customColours: {}, // Supports any colours chalk.js supports, e.g. "warn": "green" will turn warning outputs green
    fileRotationFreq: 1, // How frequently to roate files in days - will not work with anything less than 1 day currently
    directory: './logs', // Directory in which to write log files
    broadcastLevel: 4, // Level at which to broadcast to webhook if supplied
    webhook: {
        url: string
    }
}

Built-in log levels
0 - Debug
1 - Info
2 - Status
3 - Warning
4 - Error