[HN Gopher] Show HN: Universal Logger for Node, Deno, Bun, Browser
___________________________________________________________________
Show HN: Universal Logger for Node, Deno, Bun, Browser
Hey everyone, I had posted about my project https://adzejs.com a
couple of years ago and it was met with a lot of interest, so I'm
writing about the major v2 update that's just been released to see
if anyone is interested. What makes Adze interesting compared to
other logging libraries like pino, bunyan, winston, etc? Adze is
universal. This means that Adze will "just work" in all of your
environments. This is especially handy when working with SSR
projects like sveltekit, nuxt, next, etc. You can also use Adze
with Bun or Deno without any special adaptations or considerations.
Adze 2.x is also smaller (13.29kb minified and brotlied) and faster
than the original. Benchmarks put it at generating 100,000 logs in
~700ms. Version 2 also offers a cleaner API than version 1 as it
no longer uses factories and instead uses static class methods.
import adze from 'adze'; // Generating a log
adze.timestamp.ns('foo').log('A log with a timestamp and
namespace.'); // Making a child logger const
logger = adze.timestamp.ns('foo').seal(); logger.log('A log
with a timestamp and namespace.'); Adze 2.x comes with
support for four different types of log formats out-of-the-box.
These formats include: - a human-readable pretty format - a
machine-readable JSON format that is compatible with the Bunyan CLI
- a format for common logs - and a format for simple stdout logging
Adze 2.x also offers better extensibility support. You can now
create custom formatters and custom middleware for modifying log
behavior or transporting them to another source (like a file, etc).
Log listeners are also still supported. Changing formats is easy.
import adze, { setup } from 'adze'; setup({
format: 'json', // <- Change with an env var });
adze.withEmoji.success('This is a pretty log!'); Adze 2.x
also includes a handy new template literal logging feature for
times where you are repeating logs frequently with slightly
different messages (like error messages in a catch). Adze offers a
new sealTag terminator that will seal your configuration into a
template literal tag function to further simplify your logging.
Example import adze from 'adze'; //
Let's create a reusable ERR tag with emoji's, timestamps, and the
"my-module" namespace. const ERR =
adze.withEmoji.timestamp.ns('my-module').sealTag();
try { // do something that could fail... } catch
(e) { ERR`Printing my error as an error log! ${e}`;
} There is much, much more to Adze than what I can present in this
post, but please check it out at https://adzejs.com and let me know
what you think! Try it out! Also, please give it a star to bookmark
it at https://github.com/adzejs/adze if you might use it in the
future! I appreciate any feedback as well. This has been a huge
labor of love for me and I hope it benefits you all as well. Thank
you!
Author : ajstacy06
Score : 12 points
Date : 2024-09-16 15:33 UTC (7 hours ago)
(HTM) web link (adzejs.com)
(TXT) w3m dump (adzejs.com)
| SahAssar wrote:
| > Adze is universal. This means that Adze will "just work" in all
| of your environments
|
| I'm not sure what this means. console.log is also universal (at
| least for the platforms mentioned), do you mean that client side
| logs are shipped to the server?
| difosfor wrote:
| I guess it provides a complete console like API in all cases
| where some environments offer fewer console methods?
| SahAssar wrote:
| I'm pretty sure all the mentioned runtimes support all the
| standardized console methods, and it does not mention
| anything about compatability with more restricted
| environments like quickjs or embedded js.
| ajstacy06 wrote:
| It's universal meaning it works in the web browser and the
| backend without any configuration. All other loggers work in
| one or the other, or if they work in both the functionality is
| severely limited. Winston and Bunyan only work server side
| because they use node fs streams. Pino is primarily designed to
| be a server side library, but it can run in the browser by
| using browserify and using limited funcionality.
|
| Of course console methods are universal. This library isn't
| providing console methods, it's providing enterprise/production
| level functionality on top of the console.
|
| If you want to use Winston in Sveltekit or the like, you have
| to wrap browser checks around parts of it, otherwise it will
| explode when bundled.
| SahAssar wrote:
| Right, I usually prefer to use the built in console methods
| with some currying when needed so I might not be the
| audience. This has worked well enough even for "enterprise"
| use-cases.
|
| If I may give one suggestion maybe drop the dependency on
| 'vuepress-plugin-search-pro' (48MB) and maybe 'date-fns'
| (23MB), that seems like some really large dependencies that
| might not be required.
| Lord_Zero wrote:
| What transports are supported out of the box? Like file, S3, etc?
| ajstacy06 wrote:
| Right now daily file rotation is supported via the
| @adze/transport-file plugin. Plugins can be made using simple
| middleware hooks for any of your needs. I'm working on adding
| more right now for other services like Cloudwatch Logs, Google
| Logging, Open Telemetry, etc.
| theogravity wrote:
| Neat. It looks like it's more focused on the visual side of
| things since the screenshot shows two different ways to visually
| output the results?
|
| I wrote a universal logger that we've been using for our
| production systems for years that piggybacks on top of bunyan /
| console / etc. It's pretty much an abstraction layer that
| provides more structure to logs.
|
| It allows us to easily swap between different logging libs
| without having to change our entire codebase. For example, we
| originally started with roarr then eventually migrated to pino,
| and it was just a few lines of re-config to do so with loglayer.
|
| You use the existing config of your logging library and just feed
| the instance of it to loglayer.
|
| https://github.com/theogravity/loglayer
|
| It basically prevents problems like this: //
| Using `winston`: winston.info('my message', { some: 'data'
| }) // Using `bunyan`: bunyan.info({ some: 'data'
| }, 'my message')
|
| to: logLayer .withMetadata({ some:
| 'data'}) .withError(new Error('test')) .info('my
| message')
|
| A common use case is using loglayer + console initially, then
| swapping to something like pino later on.
___________________________________________________________________
(page generated 2024-09-16 23:01 UTC)