node-inspector VS debug

node-inspector (GitHub | NPM) lets you connect to a running app by running the node-debug command. This command will load Node Inspector in your default browser. Node Inspector supports Heap Profiling and can be useful for debugging memory leak issues.

Node-inspector lets you do some really cool things like live code changing, step debugging, scope injection and a bunch of other cool stuff. It’s bit involved to setup, so I’ll let you follow the instructions over at https://github.com/node-inspector/node-inspector

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.

Although it's used by Express, it's indeed more broadly, the way a popular NPM package called debug works, which is used internally in Express too. Under the hood, the debug package expects the DEBUG environment variable to determine what debug messages to print (could be on the console, or into a file, or into stdout to be collected by a log aggregator service).

Finally, if they're logs you want to be able to inspect in production without printing them to the console by default, you can use debug.

It is a drop-in, TypeScript replacement to enhance the widely popular https://www.npmjs.com/package/debug (230k weekly downloads).