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 loggingAdze 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!
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.1. I don't understand the use case for emojis. If I'm using a logging library in production it's so I can pipe my structured logs into an observability tool. Do emojis provide value in this case?
2. Consider including timestamps by default and adding a config option to remove of needed. I personally can't think of a time where I wouldn't want timestamps in my logs.
Lastly a question: Just because other loggers don't claim to be universal, do they actually break on Deno/Bun?
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.
https://adzejs.com/getting-started/setup.html
https://adzejs.com/reference/configuration.html#user-configu...
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?
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.
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.
- 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.
Some design feedback on the site:
> Universal By Nature
The contrast ratio on the headers is really hard to read. I skipped the hero section and began reading at where it said:
> which means it can be executed on the server side or the browser side without any extra considerations. Use it anywhere!
And I totally missed it's a logging library - I was expecting to see a new web framework. My preference would be to put the Simple, Chainable API section before.
when I install it it seems to depend on vuepress-plugin-search-pro which requires yarn 2 berry. not sure if you are aware this extra hurdle