npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

isnode-mod-logger

v0.1.2

Published

ISNode Logger Module

Readme

ISNode Logger Module

Introduction

This is just a module for the ISNode Framework. To learn how to use the framework, we strongly suggest obtaining a copy of the Hello World example.

The logger module is responsible for handling all logging from the core application server, it's module dependencies and services loaded in to the server. It is built in an extensible fashion - where additional log "sinks" can be added to the module as it is further developed.

The current version of the logger module supports two log sinks - STDOUT (default) and file-based logging. Configuration of the logging module (including which log levels to expose and which sinks to activate) exists within the app server config.json file, within the "logger" object (in root of config.json).

Methods

log(level,logMsg,attrObj)

Synchronous Function. Logs a message to all configured log sinks.

Input Parameters:

  1. level - (String) The log level. Available options are - "startup", "shutdown", "debug", "warning", "error" and "fatal"
  2. logMsg - (String) The free text message that is to be logged. Eg; "System is starting up..."
  3. attrObj - (Object) Optional. A JSON object containing any additional data to include in to the log. The current version of the logger module does not pass this additional data to any of the existing sinks

Returns: This method does not return anything.

Code example

// The below use case assumes that you have an instance of the isnode master object

var log = isnode.module("logger").log;
log("debug", "Instantiating the Data Module");

/* 
  If STDOUT (or console) is configured as a log sink, it would be expected that a new line would be printed to STDOUT (visible within the console/terminal) that looks something like - "2019-04-06T05:57:57.930Z (debug) Instantiating the Data Module"
*/

Configuration Example

/*
	Within the below example:
	1. "logger.enabled" must be set to true for any logged messages to be passed to any activated sinks
	2. "logger.output" contains a series of attribute-value pairs representing each log level that should be passed to the sinks. Ie; in the below example the log level of "startup" is defined and would thus be passed to all activated sinks
  3. "logger.logMetadataObjects", if set to "true" will dump the JSON object that was attached to a log entry to all sinks directly after the log message. This may be an error object, stack trace or similar. This should really only be set to "true" for debugging purposes.
	4. "logger.sinks" contains a series of sink objects - each representing an available sink.
	5. Each sink object has a parameter (eg; "console") that represents a supported sink. Unsupported sinks are ignored
	6. Each sink object (at a minimum) has an "enabled" attribute that allows you to enable/disable each sink, irregardless of whether the logger module is enabled. Ie; for a message to be passed to a sink - "logger.enabled" must equal true AND "sinks.file.enabled" (as an example) must also equal true. If "logger.enabled" is true, but only some sinks are enabled - only those sinks that are enabled will receive log messages.
	7. Some sinks (like file) have custom attributes. For example - you can define "file.location", setting it to the path+file that you want to log to. In this use case - if "file.location" is not provided, it will default to "./logs/isnode.log" (in the root of the application server folder)
*/

{
  "logger": {
    "enabled": true,
    "output": ["startup","shutdown","debug","warning","error","fatal"],
    "logMetadataObjects": false,
    "sinks": {
      "console": {"enabled": true},
      "file": {
        "enabled": true,
        "location": "./logs/isnode.log"
      }
    }
  }
}