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

5w-logger

v1.0.1

Published

5w logger library

Readme

5w Logger

How to use


...

import * as logger from "5w-logger";

const requestId = req.requestId
const event = getMadeUpEvent()
const context = getMadeUpContext()

const logger = new logger.LogSpan(requestId)

logger.info(`lambda.handler.start`, `Calling Lambda callback.`, `request`, 'SYSTEM', { event, context })
logger.info(`lambda.handler`, `Logs have been parsed and transformed. Ready to push into separate destinations.`, `debug`)
logger.info(`lambda.handler.firehose`, `Pushing logs to Firehose.`, `debug`)
logger.error(`lambda.handler.firehose.catch`, `Could not push logs to Firehose.`, `debug`, system, { error })

// Uh at this point I'm pretty sure you know how to use this... Try it out.

...

Target

Use logging to ease debugging problems, improve security auditing, improve identifying problems in security, make logging compliant to ISO 27002 standard.

Snippet from the Finnish Standards Association SFS's ISO 27002 description:

"Event logs recording user activities, exceptions, faults and information security events should be produced, kept and regularly reviewed."

Logs should answer to 5W or When (was the activity performed), Whence (the activity originated), Who (or what performed the activity), What (activity was performed), Where (in the system the activity got handled). Each activity should have its own unique identifier to ease the audit trail.

5w Logger is inspired by checkout-logger TypeScript library (https://github.com/CheckoutFinland/checkout-logger)

Structure

{
    "timestamp": "2017-11-08T07:27:04+00:00",
    "level": "info" | "debug" | "error" | "warning",
    "rid": "1232131",
    "type": "person.viewed",
    "message": "the actual content that was logged for magic crap",
    "group": "audit" | "request" | "response" | "debug" | "session" | "security" | "technical",
    "user": "SYSTEM",
    "meta": {
        "some": "info"
    }
}

Timestamp

Well formatted timestamp. Generated automatically.

Levels

Supported log leves are info, debug, error and warning.

  • Error: Use when the system has run into a fatal exception that we cannot automatically recover from and require attention from developers.
  • Warning: Use for 90% of catch cases and error handling.
  • Info: Normal information type logging.
  • Debug: General developer friendly spam that is wanted in the logs for common "what the hell just happened" type of solving.

Request ID

Request ID from headers or request when it's available. Otherwise leave it empty and the Logger will generate a valid UUID-V4 for it.

Message

Freeform message that should be unique and link you instantly to the case at hand. Requires the use of higher brain functionality to get in place properly. Think of it like well formatted Git commit messages.

Type

Links the case into a specific place in the system. For example lambda.image_processing, chat_api, and so on. Again, higher brain functionality should be used when naming this. Does not need to be as unique as RID or Message. It can be a function name from a specific piece of the software or a component name or something similar.

Group

  • There supported log groups are
    • "audit"
    • "request"
    • "response"
    • "debug"
    • "session"
    • "security"
    • "technical"

Audit

Used for specific auditing trail purposes. Everything that might require somewhat reasonable auditing trail.

Request

Can contain any linking information from the client sent Request. Aims to make the request debugging and observing easier. Make sure to strip out any sensitive inputs or mask them properly.

Response

Can contain any linking information from the information sent as Response to the client sent Request. Aims to make the response debugging and observing easier. Make sure to strip out any sensitive inputs or mask them properly.

User

This can be a named user or "SYSTEM" to indicate the log row was written by the system and not directly caused by a user doing something.

Meta

Meta object. Can be any JSON document that is considered helpful in debugging and needed to maintain sensible logs. Make sure to strip out any sensitive inputs or mask them properly.