I have been working on a project with Next.js since last month and used the console.log statement in lots of components & files even though I don't remember. Usually, we use it to check API responses and some other areas of the application.
Making console statements public is not a good idea at all, it may bring your app at a security risk. Checking every file, and deleting the statement is very time-consuming & boring too. As a developer, we all hate boring tasks so, in the article here we discuss how you can say goodbye to console.log in your Next.js app from the Production environment in just less than 1 minute.
Sounds good! let's goooo...π
π Follow the steps mentioned below -
1. Install the babel-plugin-transform-remove-console package as a development dependency.
2. Create a .babelrc file at the root of your project, copy the below content & that's all.
{
"presets": [
"next/babel"
],
"env": {
"production": {
"plugins": [
"transform-remove-console"
]
}
}
}
π This is just a short trick that I used to enhance my productivity, even you should use it next time.
I will keep sharing more tips & tricks related to web dev,stay tuned!.
Thanks for reading.
Top comments (59)
I do this too but without a plugin, I simply set an empty function for console.log on prod env.
beside console sometimes people also use alert to test something. In some of our webapps we disabled alert the same way like above.. (someone once pushed alert("curse word") on friday in production, it popped up when user did something special. We got interesting mails on monday... ;)
What about?
globalThis.console = { log: () => {} };
Wow Im newbie and wanna know how I can use this.
type just like normal console.log()?
Welcome! keep learning & chill π
What will happen when I use
console.info()for example?Calling info() will cause an exception.
So a better approach would be to do the following if you are only interested in silencing console.log:
It's helpful you called this out.
That's annoying as hell for anyone developing downstream code (browser extensions etc.) to be compatible with your site/web app. Much better to use lint rules or an approach like the one mentioned in this article.
Suggestions are always welcome, keep it up. π
consol.log harming by the way when client assign her own function to grab information
with overwrite our cleaning in client side.
Just curiously, wouldn't that that prevent from errors beings logged if ever you're using something like Sentry or DataDog or NewRelic to log errors ?
nice! approach I'm gonna try it next time π
Thatβs nice and simple on Next.js.
On Angular I created a service for logging and the log level is set based on what environment you log too. I then like to use the linter to stop any uses of console.log in the code ( except in the service ) a good git hook running the lint then stops people from committing a console log in the code.
One advantage I get with this is based on the error the service can decide if it wants to send the log via REST API to an external service for monitoring.
And then y can check a session variable to either show or hide the logs on production is also possible. It will be very difficult in your minified code to find that needed session variable to set the log.level. Show default the loglevel βerrorβ and not β debugβ and with the session variable set y can show all βdebugβ level logs
Oh! making something cool is very hard but you did it, hats off you man.
Hi! Why console.logs are a security risk?
Maybe for performance reasons? Like it runs on the main thread in the browser...
Performance may be a reason π
Hey, Mirko! thanks for asking the question. Sometimes you need to console your environment variable values to check why it's undefined or not working, this may cause your credentials at risk.
Interesting π thats the only thing that always worked for me π
π
Great, now we can label all SSR code as a 'security risk'
Hey, I didn't mean that
But you said so.
console.logcan log everything the user can access in the Inspector.console.logcan only print unwanted credentials when the back-end provided them, there for you imply everything coming from the back-end is a security risk.Or saying console.log is a security risk is just stupid.
I strongly disagree. I didn't mean that at all. Here I just mentioned a situation ,how a user can put his/her credentials on risk.
That's nice trick, but It won't pass code review.
why?
Well it depends, some seniors don't even let you have a line of comment in code.
How about an ESLint rule for no console and a pre-commit hook?
This way, you don't need any ninja-hacks. You do your testing and remove them before the commit.
Hey Jakob, you are right! but If I say when your are too close to ship?
I don't think I'm following?
what do you mean? π€
Some may be thinking that why we are not allowed to use the console.log in the production plus some other development enviornemnt as well, so the answer is that if you are fetching a lot of data from Back-End and printing that data in the Front-End in any framework then it is quite possible that, that data will again some time to get printed at the console so due to this reason we should avoid printing direct data to the console.
The other thing that has been mentioned in this article is the security risk, this also put the application on the risk as well.
This plugin looks good but it is there is a need to communicate the need and usage of this plugin to the other members of the team as well. However, I appreciate that you have bring this matter of writing console log on the production deployed application. This is a critical thing to which only a few developers pay attention, more power to you and looking forward to see some important articles from your side. Good Luck.
Thanks for the detailed explanation & lovey wishes! π€
console.logs should just be used to bug check and afterwards removed. Don't leave it in the source code, especially not in big companies. You can maybe create a peek functionality in your utils, but that's that. Using build tools to remove code is just bad practice.
True π― but what do you mean by build tools to remove code ?
I prefer to create a custom logger wrapper/class and use it in app. In react apps as custom context/provider with hook to get logger instance in components.
Why? Several advantages:
"Checking every file, and deleting the statement is very time-consuming"
ESLint's rule to deny console logs + ignore them just in console logger implementation
Actually, while searching for the solution I had no idea about logger services so I solved it using the package. Yeah! thanks for the detailed solution β₯
I just add this code:
let testMode = true; // console log suppressed if false
if (!testMode) {console.log = function() {};} // to suppress console log
Could even use husky to setup custom git hooks for blocking a push or commit if linting fails
Nice trick! but what if you setup the rule late for you console.log ?