Hacker News Reader

Comment by ericyd | Hacker News Reader

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?

View on HN

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.

That makes sense! This is obviously just my preference, but in both cases I would prefer this to be a config option, so I could control it e.g. by an environment variable. Local dev? Probably don't care about timestamps and probably would enjoy emojis. Production? Absolutely need timestamps and probably don't want emojis. I realize this is a significant API change, but just wanted to share my thoughts.

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

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.

Reply on news.ycombinator.com