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?
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?
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.
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.
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
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:
to: A common use case is using loglayer + console initially, then swapping to something like pino later on.