Is console.log() in a package considered bad practise?


#1

I am writing a package that can be used to write interactive books. I have a lot of methods, and I display every step that is done with console.log().

For the moment I do this to help me debug.
But should I leave them in the package when I publish it or is this bad practise?

To be clear:
I do my error-handling with throw new Meteor.Error().
I use console.log() only on serverside.


#2

I would suggest to abandon console.log and adopt infinitedg:winston
It’s a multi-trasport async log library (console, AirBrake, database and Loggly) that allows you to gather all your log traces on the server.

I don’t have a clear answer to your question though. Honestly I don’t see many other ways to understand if something is not working in production other then logging and profiling your app.

ref: https://github.com/winstonjs/winston


#3

@massimosgrelli you are right that there are many good ways, but for a third party dev who knows nothing about your library the chrome console is a life saver.


#4

@muaddib sure. winston library is exactly this but you avoid to refactor your code 3 months for now to adopt a more structure approach.
In my case I’m using wiston library to write logs on the console and the only think I need to do was:

a. meteor add infinitedg:winston

b. create one logger object for the server and one for the client

if (Meteor.isServer) {
  Meteor.startup(function() {
    logger = Winston;
  });
} else {
  Meteor.startup(function() {
    clogger = Winston;
  });
}

c. I’m using the default log levels, so:

logger.info(..)
logger.error(...)

to trace what I need.

By default logger and clogger write on the server console – much easier than observing client and server consoles.


#5

Aargh, noooo!! :smile:

Seriosly, though, please don’t. I hate it when packages clutter my browser console or the server logs.

If the log item is a serious piece of information that needs to get recorded, perhaps for identifying problems later, and that it happens only once in a while, maybe it can be acceptable. Otherwise it is just noise. Especially in the browser. In fact I kind of consider a security threat due to its revealing nature.

You can perhaps make it opt-in. Allow your package to accept a configuration paramater that turns logging on/of, better yet separately for the server and the client.

I wish meteor had a defacto logging framework into which packages could individually register their namespaces with and the app developer themselves could configure what gets to be displayed, what gets to be diverted elsewhere etc.


#6

Hi budickda, I’m interested in your package, is it available as open source?


#7

Not yet, but I will publish it on GitHub in the next few weeks.


#8

If it’s a 3rd party package I would recommend looking for a global variable like __mything_debug__ === true and then spew out all the logs with console.log. I normally use a simple log function at the bottom of the page to abstract it away in case I need to use more intense logging like Winston later. This log fn can also check for the debug which keeps your code clean.


#9

@budicka: Nice, it would be great if you could announce it here once you’re finished. Thanks!


#10

Maybe the package should be done as a wrapper of winston logger. In this way you could get a seamless integration with packages like loggly ─ or MongoDB ─ that you might want to use once in production.


#11

winston can be a weak dependency and can be used only if it exists.

logging could also be debug only and opt-in/out by configuration.