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 🙏

© 2024 – Pkg Stats / Ryan Hefner

@akkadu/logger

v4.1.2

Published

The point is to have one unified implementation for backend and frontend. To achieve this we load logger configurations either from process.env or localStorage

Downloads

149

Readme

Logger

What is this logger thing about?

The point is to have one unified implementation for backend and frontend. To achieve this we load logger configurations either from process.env or localStorage

How to use

Installation

  • You can install with npm, yarn or bit. We use yarn!
yarn add @akkadu/logger

Importing

This works in client and server-side, pew pew pew!

// ESM
import Logger from '@akkadu/logger
// CJS
const Logger = require('akkadu/logger')

Configuration

The logger has 6 levels. Each level will log itself AND the levels below it. For instance logLevel 'info' will log info,warn,error and off. Off is implemented as a method for testing purposes

  • insane
  • debug
  • info
  • warn
  • error
  • off

The logLevel affects two things:

  1. It affects the logger initialization.

You can define the logLevel of the logger itself to be one of the following - insane - debug - info - warn - error - off

// the default way to use the logger is just to initialize it, in this case
// we read the logLevel from process.env, or from the browser environment
const logger = new Logger()
// or we can define the logLevel in the initialization
// each logger is an isolated instance, so we can have different levels of logging
// in different files if needed.
const logger = new Logger({logLevel:'info'})

The client side env reading is a bit special, so an additional word about that. To set the logLevel from the env there are 2 different ways

  • define localStorage.logLevel = 'info' to define your browser logger level
  • (default) read LOGLEVEL from process.env
  1. logLevel is used when we actually use the logger

The logLevels available for logging are

  • insane
  • insaneOnce (behaves like insane, but logs only once)
  • debug
  • info
  • warn
  • error
const logger = new Logger()
logger.info('The server is listening on port 3000')
logger.error('User object should be defined')

The default config of the logger is:

const defaultConfig = {
  logToConsole: true,
  logLevel: 'info',
  output: []
}

The options you can pass to logger are

{
 testEnv: Boolean // if we are running in test env
 logToConsole:Boolean // if we want to log to console
 outputs:[ // custom output, we will push logs to there arrays
  {logOuput:[], logLevel:string}
 ]
}

Examples

SERVERSIDE - default logLevel should be info

Let's say that we are on the serverside, and we just want to have default logs on production

 const logger = new Logger() // by default the log level is info, so anything below info will be logged
 logger.info('server is listening on port 3000') // will be logged
 logger.debug(['created new user',userObject]) // will not be logged

Now we have problems on the server and we want to also display debug logs. We can either:

 // 1. go to .env and set LOGLEVEL='DEBUG' to get all debug logs everywhere
 // 2. or change the logger initialiation in the file we are debugging
const logger = new logger({logLevel:'debug'})
logger.debug(['created new user',userObject]) // will log!

CLIENT SIDE - default logLevel should be warn

Let's say that we are in browser environment on staging. We are running a nuxt server, so process.env is available

const logger = new Logger() // the logLevel will be read from process.env - default should be warn
logger.info(['Joined room',roomData]) // should not log
logger.debug(['Sending socket message', message]) // should not log
logger.warn('this route is deprecated') // should log

Now let's say that we have problems with sending messages throught socket connection.

// 1. we can change our logger initialization in the problem file with new logger({logLevel:debug})
// 2. we can write in console localStorage.logLevel = 'debug' and refresh the page
// in both cases
logger.info(['Joined room', roomData]) // should log
logger.debug(['Sending socket message', message]) // should log
logger.warn('this route is deprecated') // should log

<3 BadgrHammer, please share any questions or suggestions to me.