screech
v1.1.0
Published
Topic based logging for easy filtering
Downloads
2
Readme
Screech
Quiet down that racket
Use a simple config file to drive topic based logging. Then, filter your logs depending on the task at hand.
Installation
No dependencies. Wrapped up with UMD boilerplate, so in theory you just drop it
in and call screech(config)
somewhere before you start logging.
Usage
Write a config object and call screech with it, like this:
var loggingTags = {
tags: [
"netio",
"auth", // just a string
{
method: "templates",
tag: "templates"
},
{ // or tagname and methodname that differ
method: "config",
tag: "templates-config"
}
]
};
screech(loggingTags);
console
object ends up decorated with methods like so: console.netio
,
console.auth
, console.templates
, console.configuration
.
Call console.netio().auth().info('GET response', responseObject)
, see
// artist's rendition of a console line
(i) netio auth :: GET response > Object responseObject{} <- properly rendered object
// ^ ^ ^
// | | |_ expander carot
// | |
// | ----- your first arg
// |
// --- your tags
on the console.
Methods
Currently supports
log
info
debug
warn
error
Note
Each time you call one of your tag methods, a tag string is pushed into an array. When you call one of the supported logging methods, that array is flushed. If you fail to call the intended logging method where you intend to log with it, you'll end up with erroneous logging tags showing up on the next call to one of the aforementioned supported logging methods.
TODO
- [x] test in Node (looks like it works gud)
- [ ] dir?
- [ ] memory leaks?
Why you do this?
This is handy for teams to codify the tags they can use to filter logging in the dev console. In our group, we kept commenting/uncommenting logging statements back and forth across commits, which is dumb. So we built this so we could stop fighting. :sparkles: :poop: :sparkles: