search

2graphic / sinap-ide

Sinap IDE development project.
7 stars 1 forks source link

Logger library #346

Open Sheyne opened 7 years ago

Sheyne commented 7 years ago

Reviewing Dyllon's PR it looks like he used a logging library. I think we should be consistent with how we log. What I like about console.log is that in vscode/chrome debuggers, this objects it prints are introspectable. Thoughts?

danielscottjames commented 7 years ago

I vote we just use console.log, I still don't see the point of the logging library.

slaymaker1907 commented 7 years ago

@Sheyne that's why I also offer LOG.info. I think it makes stuff more easily filterable, plus if we ever want to get really fancy and have some logging config to turn on/off certain loggers, I wrote it so that would be easy.

I think it also encourages logging to view how things are being processed in the app. That was a big reason of why it was so easy for me to figure out that the PluginManager was causing a bunch of reloads.

I didn't pull in a library because it didn't seem that difficult to write and I have very little trust for the JavaScript community.

cj-dimaano commented 7 years ago

I'm not really convinced that we need a separate logging library for debugging. I also don't really see the benefit of having a logging library for runtime purposes, either.

Looking at the commit, I'm failing to see how LOG.* is any different from console.log other than with its semantical use. If anything, I feel that LOG is adding unnecessary bloat to our infrastructure. How does our application benefit from a logger when running in production mode?