Show HN: I've made an easy to extend and flexible JavaScript logger

[inshinrei]

hi! I've made a logger for JS/TS. It's easily extendable, easy to use and configure.

Would like to hear a feedback from you!

[Thomaschaaf]

Can you give insights into what makes it different from e.g. pino[1]? It's amazingly even faster than console.logging because of the way it buffers the data.

[1]: https://github.com/pinojs/pino

[matsemann]

Pino seems to be catered for backend, while this project looks to be more for web clients?

[inshinrei]

The primary purpose of the "halua" logger is to provide easy control over log levels and output systems in a single place

As of performance, let's address why "pino" is faster than console.log. Pino avoids using the console directly, as it is designed for the node environment and appears to utilize stdout.write for output. This approach gives Pino a performance advantage in benchmarks. As of now, "halua" is yet to be optimized. Your comment prompted me to conduct a quick benchmark tho. If you're interested, here are the results for 10_000 iterations:

// halua (console): 358ms (NewTextHandler(console.info))

// pino: 233ms

// halua (stdout): 253ms (NewTextHandler((data) => process.stdout.write(data)))

There's also JSON handler in halua, which is 10%-20% slower than text handler

[gus_massa]

In case someone miss the link at the bottom of the readme, there is a detailed explanation in https://github.com/inshinrei/halua/blob/main/docs/tour_of_ha...

[inshinrei]

thanks for highlighting, I've updated the README file and move docs on top with "documentation" header so that it will be easier to find

[cluckindan]

It would be great to have debug-like namespacing / filtering, combined with log levels.

https://www.npmjs.com/package/debug

[inshinrei]

will do

[lnxg33k1]

Doesn't seem flexible, seems mostly non-alterable, probably easily extendable is a thing, but I've been mostly productive with stuff that would allow me to don't duplicate existing behaviours but hook into them, that's flexibility imho, if I want to change some of the behaviour of an existing handler I have to reimplement it completely, then it's not flexible, the classes also seem quite giant, making me thing even more it's not really flexible/extendable

[inshinrei]

i'm also leaving an example of production app setup here:

import {Level, halua, NewTextHandler, NewJSONHandler, NewWebConsoleHandler} from 'halua'

// an array of handlers that would accept logs

let handlers = [

  NewJSONHandler(writeToZipArchive, {level: Level.Info}), // writes to client-size archive, only logs that are Info-Level or higher

  NewTextHandler(sendToServer, {level: Level.Notice}), // writes to server, only logs tat are Notice-level or higher
  
  NewTextHandler(sendUserAction, {level: Level.Info + 1}), // we will log user actions on a different level, so that it will be easy to filter

  NewTextHandler(sendToErrorMonitoringSystem, {level: Level.Fatal}) // writes to monitoring system

]

if (debug) {

  handlers.push(NewWebConsoleHandler(self.console)) // writes to web / nodejs console

}

// now we have to apply the handlers we created

let logger = halua.New(handlers)

// or

halua.setHandler(handlers)

// later, you may call .New on any logger instance to get a new instance