link-preview-generator VS debug

It would be great to have debug-like namespacing / filtering, combined with log levels.

https://www.npmjs.com/package/debug

debug is imported and is assigned to base . In the debugLogger function, base is extended with the parameter passed.

It seems a lot of thought was put into the design of LogTape. I may integrate my logging tool with LogTape. My tool needs the callsite, so I don't think I can just write a LogTape sink; I think it would also have to wrap/extend LogTape itself.

---

I built a DX-focused logging library on top of debug-js. Notable features of https://github.com/Leftium/gg:

- Automatic namespaces based on calling function + path to source filename/path.

- Can be inserted into the middle of expressions.

- Can output a link that opens the file in your editor/IDE of choice.

- Simple to disable

- Diagnostics/hints to help with installation/configuration

---

I was surprised by the amount of logs already being output (by Vite) when I simply added https://github.com/debug-js/debug to my project.

Fortunately, debug-js output is very simple to filter via ENV and/or localStorage.debug

---

What I look for in a logging library (with more focus on dev/debugging than production):

- Easy to add new logs.

- Easy to identify the location of the code that triggered the log. I noticed a lot of my logging was simply to indicate the start and maybe end of a function call. If needed, I might add additional logs between these.

- Easy to surgically disable/filter groups of logs. Should be easier than commenting/uncommenting calls to logger. Otherwise I end up with lots of uninteresting log chatter (or I delete log statements, only to add them again later...)

It's absolutely not an anti-pattern if you have appropriate tools to handle different levels of logging, and especially not if you can filter debug output by area. You touch on this, but it's a bit strange to me that the default case is assumed to be "all logs all the time".

I usually roll my own wrapper around an existing logging package, but https://www.npmjs.com/package/debug is a good example of what life can be like if you're using JS. Want to debug your rate limiter? Write `DEBUG=app:middleware:rate-limiter npm start` and off you go.

Debugging libraries: The debug package (by TJ Holowaychuk) lets you enable namespaced debug logs with DEBUG=app:*.

Number of dependencies: one way to tell if a library is not too challenging to be used as study source is based on the production dependencies count. The fewer the better. For example, I chose debug because it only has 1 dependency (ms), while the rest of the code relies on core NodeJS modules - which is exactly what I was looking for - to learn how to build a library from scratch, not off the shelf libraries with many external deps, which in turn are based on more deps. There you go, dependency hell.

Another way to solve this is to have the logs in place, but only enable them conditionally. If you enable all the logs are the time, you only get a lot of noise that won't help you. If you are using JavaScript, you can use the package debug to add logs that are active by the DEBUG environment variable.

I'm using the debug package: https://www.npmjs.com/package/debug, but some reason I don't see millisecond diffs, which would be really useful.