How to remove console logs in your production code

Written by

Walter G.

Published on

November 17 2021

Every JavaScript developer loves using the console in order to test out and debug their applications. I do as well. It's just too convenient and takes very little effort to do. And best of all? You can pretty much output anything and everything.

console.log(variable1, variable2, 3, 'car'); // outputs everything

You can even add color to the black and white screen if you wanted to.

But there is one issue with the overuse of console logs. When your application is ready to go live, you have to get rid of them. Each and every one.

What happens if you don't get rid of them you may ask? Well. Nothing really. But it's just bad practice to litter both, your code and the console needlessly with messages intended only for the developers.

There are a few solutions to this issue though, starting with the most obvious, but probably least preferred method.

Comment them out

The problem with getting rid of your console logs completely is that at some point in time, you are going to need them again in the exact same place that you left them. I promise you. Not until you are 100% done with a project and everything is live will you feel comfortable getting rid of your debugging code.

Which is why I don't typically advocate complete removing them from your code. But you can comment them out.

// console.log(var1);

This only solves the issue of not having anything in the console on production. But it doesn't actually get rid of the actual problem.

And that's that you shouldn't have any debugging code whatsoever in your live production code.

More than anything, it avoids potentially giving away too much information about how your code is structured. I've worked with developers in the past who have accidentally logged relatively sensitive information to the console, only for it to be discovered weeks later.

Not common, but it can and does happen.

So not the most ideal solution, but it works in some regards.

Use ES Lint 'no-console'

If you haven't heard of ES Lint, then now's the time. Because it's a pretty valuable tool for any JavaScript developer.

ESLint is essentially a tool that you helps to identify issues with your JavaScript code based on a set number of rules that you specify.

In some cases, it can even fix the code for you, which is super valuable on a high complex system with many moving parts.

One of the rules that you can set, is the no-console rule, which essentially flags any use of a console.log in your code.

/* eslint no-console: "error" */

// custom console
Console.log("Hello world!");

The rule set above would result in the following error message from ES Lint.

This is a great tool to run before any production push. However it doesn't solve the problem that was mentioned earlier.

And that's the fact that you will more than likely need to rely on the same console messages multiple times in the course of development. So deleting them isn't really a valid option.

Which brings me to the last solution to this problem. And the one that's my personal favorite.

VS Code Logpoints

This is strictly a Visual Studio Code feature that was added in 2018.

Logpoints are a debugging feature that let you add breakpoints to lines in your code. But unlike a traditional debugger, logpoints don't break into the debugger but instead simply log the values to the console.

Logpoints allows you to "inject" logging statements into your application logic, just like if you had added logging statements into your application before starting it.

They are injected at execution time and not persisted in the source code, so you don't have to plan ahead but can inject Logpoints as you need them.

Another nice benefit is that you don't have to worry about cleaning up your source code after you are finished debugging, which solves the biggest problem that console.log brings with it.

The caveat here being that you need to be using VS Code for this to work.

If you're a JavaScript developer though, there is a good chance already that this is your IDE of choice.

And lastly...

It's not the end of the world if you have left over console messages in your production code. Every website (no matter how professional) has the same issue.

So by no means am I promoting not using the console to debug your code. In fact, use it as much as possible because it will ensure that you have safer and more accurate code and logic.

But if you are looking to have cleaner code and follow the best practices that many professional developers follow, then you now have a few options to consider when working towards removing them.

Comments

No messages posted yet

Add comment