justmoon
commented
6 years ago Agreed. Here are some of my thoughts on best practices.
debug for very verbose debug messages
console.info for regular messages you would want most users to see
console.warn for warnings
console.error for serious errors
And, personally, I also use console.log for temporary debug statements I plan to remove before committing.
For upstream modules, it's good practice to avoid console.info to avoid unwanted console output. (console.warn and console.error are still fine to warn the user that something went wrong.) This module, codius, should try to gather enough information so it can console.info useful output about what it's doing. That way, when something does go wrong, there is some context about what it was attempting.
For all log messages of any kind, always include useful variables, not just an error message. Best practice is to use a key=value format to make the log more easily parseable. I like this simple format: something happened. key1=value1 key2=value2
For the top-level user-facing module, I created riverpig which is a simple logging library that supports namespacing (like debug), different log levels, and colored output. Could be useful for this module, unless we want to put more effort into highly customized console output.
traviscrist
People are trying to test their codius host setups using the example on the codius tutorial and/or codius-example repo.
In the failure case, the cli just returns empty - the user doesn't know what went wrong.
They can get the full log using
DEBUG=*, but that's not very intuitive (I actually discovered this looking into the source code - good oldebugmodule - even the readme for this repo doesn't mention it).Strong urge that errors are outputted to console with a short blurb on how to get the full debug logs.