HackerTrans
TopNewTrendsCommentsPastAskShowJobs

ajstacy06

no profile record

Submissions

Show HN: Universal Logger for Node, Deno, Bun, Browser

adzejs.com
51 points·by ajstacy06·há 2 anos·24 comments

Universal TS Logging (SSR, Bun, Deno)

adzejs.com
1 points·by ajstacy06·há 2 anos·1 comments

Help I have a JavaScript Lib that blows away competition but nobody knows of it

adzejs.com
25 points·by ajstacy06·há 3 anos·25 comments

comments

ajstacy06
·há 2 anos·discuss
Yes, that dependency was there by mistake and has been moved to devDependencies in 2.0.11
ajstacy06
·há 2 anos·discuss
It is actually also a config option that can be passed to the setup function. Many of the modifiers actually just change the config value under the hood. All production formatters have timestamps by default, only pretty does not so it shouldn't be anything you need to worry about. You can also set timestamps globally in the setup function.

https://adzejs.com/getting-started/setup.html

https://adzejs.com/reference/configuration.html#user-configu...
ajstacy06
·há 2 anos·discuss
Puns for the win
ajstacy06
·há 2 anos·discuss
Thanks for the feedback!
ajstacy06
·há 2 anos·discuss
You can install 2.0.11 for the fix now!
ajstacy06
·há 2 anos·discuss
It appears I had that mistakenly in the dependencies instead of devDependencies. I'm correcting it now and will release a patch. Thanks for the heads up!
ajstacy06
·há 2 anos·discuss
Also, on the topic of timestamps, some of the formatters do have them on by default. The pretty formatter which is mostly for dev does not because its not as necessary. I hope that helps explain that decision :)

As for emoji's, they are off by default and are really only for dev with the pretty logger. You are right in that you probably would not want them in production. You would probably use a different formatter like "standard" or "json" anyway which doesn't allow them.
ajstacy06
·há 2 anos·discuss
They may or may not break on Deno or Bun, but most will not work in the browser or if they do they are severely limited in functionality. This library was actually born out of my frustration with trying to generate logs and transport them from the browser. Plus, in my past experience, it was a bit of a pain to use older logging libraries with new SSR frameworks. They also mostly have poor, bolted-on typescript support.
ajstacy06
·há 2 anos·discuss
First of all, if that's all you need then by all means, keep doing that. If you need any of the following, maybe consider a library:

- First-class TypeScript support (not bolted-on)

- Wraps and extends the entire standard API

- A convenient chainable API

- Log Listeners for capturing log data

- Middleware support for plugins and transporting logs

- Log annotations such as namespaces, labels, and other meta data

- Four formats supported out of the box:

  - Pretty - Human readable logs that are easy on the eyes
  
  - JSON - Machine readable logs that are compatible with the Bunyan CLI
  
  - Standard - Human readable stdout logs
  
  - Common - Logs that adhere to the Common Log Format
- Everything is customizable and configurable

- Tools for caching, filtering, and recalling logs

- Support for creating log threads to track data across multiple scopes

- Convenient child logger API's

If you look at the readme you'll see adze is 8kb bundled and gzipped. It's ESM so it has tree-shaking support. It's tiny. The Vue dependency is for the docs.

https://bundlephobia.com/package/[email protected]
ajstacy06
·há 2 anos·discuss
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.
ajstacy06
·há 2 anos·discuss
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.
ajstacy06
·há 2 anos·discuss
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!
ajstacy06
·há 3 anos·discuss
Didn't realize adze().log() was overly complicated. If your use case is that basic then that's literally all the code you need from Adze to do your task. It also does alert, error, warn, info, success, fail, debug, and verbose out of the box.

https://adzejs.com/guide/default-terminators.html
ajstacy06
·há 3 anos·discuss
Yes, I need to refocus the homepage content to show the parts that are better. I think I need to separate the API reference from the Getting Started guide (it's kind of mixed).
ajstacy06
·há 3 anos·discuss
Ya, so when it comes to logging in the frontend, most folks just build an app and throw it out there, but when Joe/Suzy experience a bug, the frontend folks have no idea what it is. Console is really only useful before production. Ideally you would monitor your frontend application the same way you monitor your backend applications. People would find it insane to have no logging in backend apps in production, but people seem to not care about it in the frontend.
ajstacy06
·há 3 anos·discuss
Ya, I need to be more considerate of demo'ing on mobile. I had wrongly assumed developers would look at libraries from machines they are working on.
ajstacy06
·há 3 anos·discuss
Thanks for the feedback! It appears a home page redesign is in the works :)
ajstacy06
·há 3 anos·discuss
Good point. I should make it more clear what advantages it has over other libraries. The main one you likely won't find great support in other libraries is node and browser. Most only do one or the other.
ajstacy06
·há 3 anos·discuss
That's a great point. I've been thinking about making an interactive widget playground for the library.
ajstacy06
·há 3 anos·discuss
Hey friends,

I have written an open source JS lib named Adze that I believe blows away all of the competition. It is a logging library that runs natively in both the browser and node without any special considerations. It also offers every feature you could want for formatting and annotating your logs as well as a convenient interface for processing your logging data without requiring silly plugin API's.

The API for Adze is also chainable, fully wraps the standard console API's, is TypeScript native, supports mapped diagnostic context and micro-frontends.

My question is, what tips would you give me for marketing the library and making people more aware of it?

I'm also very open to constructive criticism on the library and codebase and would love any feedback that I could be provided.