Looks really nice and will give it a try on our codebase as an alternative to Winston.

Funny thing : one of the colleagues was unhappy when we proposed to define the logger as an interface, allowing us to switch implementation in one line. "We will never change the logger" he said...

    export interface Logger {
        debug(message: LoggerMessage, ...meta: unknown[]): void;
        error(err: Error): void;
        info(message: LoggerMessage, ...meta: unknown[]): void;
        trace(message: LoggerMessage, ...meta: unknown[]): void;
        warn(message: LoggerMessage, ...meta: unknown[]): void;
    }

Great job ! Emojis can actually be useful while working locally, especially to detect errors quickly.

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.

Looks like a cool project, and props for making it universal for all runtimes. A few pieces of feedback:

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?

I enjoyed the punny forestry imagery. Going beyond console.log in a sveltekit app was on my todolist so I’ll try this out.

> 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?

Hey, cool project! Will have to try it out next time.

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.

cool I was looking for something like this, attractive site too

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

What transports are supported out of the box? Like file, S3, etc?