Deactivate console.log on production (Why and How)

Henry Falade
Mar 8 · 3 min read

As a JavaScript developer, console.log(…) is a savior, so is alert(…). Savior?Well, they both come in very handy when we are debugging, right? What more savior does a developer need?

Photo by Markus Spiske on Unsplash

Unlike alert(…), console.log(…) doesn’t block page rendering and it doesn’t come as a pop-up nor does it appear within our page’s view, so, it is the most used and most loved by developers. The results from console.log(…) are only visible in the console of your browser (chrome, Firefox, etc.).

WHY SHOULD I DEACTIVATE console.log(…) IN PRODUCTION?

Well, if this question is in your head, I guess it means you’re not dogmatic and you’re inquisitive. If its not in your head, it doesn’t mean otherwise : )

When debugging or making sure APIs or other resources are working well, we tend to log a lot of information into the console, including data that errrr… should be hidden (at least without unnecessary diggings by evildoers or over inquisitive users). If you are like me, then it is only normal you use console.log(…) a lot and forget to remove them (at least not all) from your codes.

Now, imagine you visiting a website and seeing a bunch of logged data in your browser’s console, apart from it being messy LOL… it gingers you to start looking for what isn’t lost : )

My advice is therefore either go through your code properly and remove all the console.log(…)s within your code-base or just deactivate it at the top.

Photo by rawpixel on Unsplash

HOW TO DEACTIVATE console.log(…) IN PRODUCTION

If you got here, I’m assuming I have been able to convince you to make sure console.log(…) is deactivated on your production server. Here’s how to go about that:

  • Make sure your application has an environment variable that differentiates a staging environment from a production environment: For example, in Laravel, you will be using an .env file to store environment variables, and there is a variable that differentiate environments (APP_ENV=local/staging/production)
  • Now, within your page before the importation of your custom js file, you should overwrite the console.log(…) function if the APP_ENV is set to production. Take a look at the snippet below.

You must be angry at me for taking you through a long read just to show you the magic of an equal to sign. My bad, just had to make sure you got why this should be used.

BREAKDOWN OF THE SNIPPET

The snippet assumes we are dealing with an application with a PHP back-end. Same logic can be applied with other languages, so far you have environment variables set.

  • variable env retrieves and store the ENVIRONMENT (local/staging/production) you might have saved with PHP.
  • Then a check is put in place through a conditional statement to check if your app is on the production server (as set by you),
  • if that is true, it overwrites the console.log function and sets it to a redundant and empty function. Thus, invalidating every usage of the function in codes below it.

NB: this must be placed above all your custom JS codes.

Now you are rest assured your console.log(…) will work properly on your local or staging server but will not output anything on your production server.

Comments, suggestions or corrections are welcome.
Thanks!

Click the link below to learn how to create an environment variable file in a PHP application.

https://medium.com/@hfally/how-to-create-an-environment-variable-file-like-laravel-symphonys-env-37c20fc23e72

Henry Falade

Written by

A programmer and web tech enthusiast! Love Angular & Laravel.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade