A nice little dash. Surprisingly, I found the most valuable part of it is honestly just splitting stdout/stderr, as the rest of the data is relatively easy to access (except event loop lag, but there are packages like toobusy[https://www.npmjs.com/package/toobusy-js] to help with this).
It doesn't work in combination with nodemon or babel-watch (yet), but the code looks very clean & simple so I assume it'll be an easy update.
Not necessarily good to separate stdout from stderr. Sometimes you want to see an error in its context.
Then, if you have 800 requests per second, reading logs in this way will not be very valuable.
Best way I have found to manage logs is:
- give requests a unique id. use that id when logging anything related to that request.
- have logs in unformatted json format for size. e.g: use bunyan to save them, use bunyan-cli or jq to read them.
- use unix tools like grep, sort, uniq, wc, etc. to find things...
- you can also feed your logs to elasticsearch/kibana or another aggregator. e.g: logio.org.
Again, jq is very useful processing json. it can help you query logs and find what you need, and format results in any arbitrary way. Make your logs queryable, don't save formatted logs. you will make your life difficult in this way.
Is there anyone interested in improving the UX of the stock nodejs in-terminal debugger but who just needs money to do so? Because the experience of "run this single test and pop into the debugger at line 14 to poke around" has several warts that I'm surprised haven't been fixed yet:
1) Having to call `cont` at the beginning rather than the debugger stopping at the actual place where the `debugger` line is placed.
2) Having to call `repl` in order to start printing things
3) After calling `repl`, not being able to get back to the mode where you can go to the next line and jump into functions.
4) If jumping into an express.js route, inspecting the request sometimes just results in the message "no frames".
Why not use chrome devtools to debug node? It's now a built-in feature as of v6.3.0 and no longer requires the 3rd-party and kinda buggy node-inspector module. Just use the --inspect command-line flag. (--debug-brk too if you want it to start paused on the first line.)
maybe you're on a test server (no GUI) and for whatever reason you also don't want to remote debug with node-inspector, you want it all quick and dirty via ssh ;)
Python's "baked in" command line debugger that you get via `import pdb; pdb.set_trace()` is awesome for this kind of quick and dirty ssh debugging so if you're looking for inspiration on how node's command line debugger should work, check it out. I always miss python's pdb when working with JS or PHP or... anything else.
I believe you could use SSH's -L flag to forward a port from the server, so you could run `node --inspect ...` on the server and use Chrome on your local machine.
Whenever there's an error which is non-fatal. Do console.error("Your error") and it'll write to stderr or alternatively process.stderr.write("Your Error\n").
Albeit rare in normal JS because it seems most things are fatal when they break, lots of libraries use it.
It doesn't work in combination with nodemon or babel-watch (yet), but the code looks very clean & simple so I assume it'll be an easy update.
If you're looking for more granular reporting & monitoring I can heartily recommend pm2's web dashes [https://github.com/Unitech/pm2]. There are also terminal dashes around like pm2-gui [https://www.npmjs.com/package/pm2-gui].
Nice (and clean) work @formidable.