Create-react-app: Strip console logs from production builds

[dbachrach]

Proposal: Automatically remove console.log statements from production builds while still keeping them in development builds.

Reasoning: Log statements can be useful to keep in development builds. However, they can be unnecessary and potentially sensitive to include in production builds. Currently, CRA does nothing with console logs, so if you want to have log messages in development, they must be manually removed for a production build.

Potential Solutions: There is a webpack loader that can strip aritrary code including console logs https://github.com/yahoo/strip-loader. We could also update our use UglifyJsPlugin and provide the drop_console option to the compressor.

Downsides: Anytime code is removed from builds weird situations can arise. Particularly bad would be unintentional side effects inside of a console log statement, which would be removed only in production and may lead to hard to debug problems. Additionally, there may be times where you deliberately want to include specific log messages in production. We would then have to support a way to flag certain console log lines to not be stripped.

I wanted to open the discussion because I couldn't find any prior issues about this feature.

[tbillington]

What about console.error ?

[FFX01]

I like the idea.

Anytime code is removed from builds weird situations can arise. Particularly bad would be unintentional side effects inside of a console log statement, which would be removed only in production and may lead to hard to debug problems.

I am a bit weary about this as well. Though, I am having difficulty coming up with cases where a console.log() call would be essential to application itself.

What about console.error ?

I think removing console.error() or console.warn() would be a bad idea as some people use them to display error messages with information on where to submit bug reports and such.

I am, however, new to this project, so take my words with a grain of salt.

[dvkndn]

Additionally, there may be times where you deliberately want to include specific log messages in production. We would then have to support a way to flag certain console log lines to not be stripped.

You are correct that there are cases we actually want to use console.log (for example, some company use that to show hiring developer message). Therefore, strip all console logs is not suitable for all, or in other words, require a flag. If some feature require a flag, I think it is not suitable to be included in CRA.

Anyway, for feature like this, I think forking CRA is a good option.

[dbachrach]

What about console.error ?

I tend to agree with @FFX01 that this should not be stripped, but I don't use these often enough to say for sure.

You are correct that there are cases we actually want to use console.log (for example, some company use that to show hiring developer message). Therefore, strip all console logs is not suitable for all, or in other words, require a flag. If some feature require a flag, I think it is not suitable to be included in CRA.

This was the same example I was thinking of for wanting to keep some specific logs in produciton. However this is a line-level flag, not a CRA config-level flag. I'm not sure where the no-configuration line should be drawn for this specific feature-- open to thoughts around this.

[gaearon]

I think this may be too surprising and for this reason likely not a good fit for this project. We may add a lint rule to only be used during npm run build for it, but I don't think we should strip them.

[omninonsense]

Sorry to comment on a closed issue, but what about only stripping console.debug? I agree that log, warn and error should remain, though.

[afilp]

Also sorry for asking on a closed issue, but could this be an option somehow? Thanks.

[alexgvozden]

one more vote for stripping console.log as an option
tonite I had second time of app being unusable in release just because of console.log

in both cases it was console.log of whole component, ScrollView component (from ref => this.scroll = ref } and then later logging it to see if it registered itself...

Thanks in advance for giving us an option to remove the logs on build

[tbillington]

It's easy to set up a log function that checks for the env build setting (development vs production) and logs/doesn't log appropriately. Pushing this up into CRA seems like bad practise. If you don't want your logs in production, don't call console.log :P

function log(...args) {
  if (process.env.NODE_ENV === "development") {
    console.log(...args);
  }
}

[alexgvozden]

I get what you mean but instructing everyone to do this to avoid breaking react native is not going to work plus that is still function calls instead of removing them fully, I'll check if actually this solves issue as var is still passed to function

basically React Native breaks on functionality that should work (possibly not RN fault, but avoidable)

I suspect issue is that known behaviour is that console log is not cleared with garbage collection and something happens there
so it would be quite logical to have option to trim console logs on build, like any other javascript project
it's really problematic that this is not happening in debug iOS version but in release only and that's the cause of all evil

[tbillington]

This isn't react native though, CRA is a boilerplate for react web applications. How will modifying the build of CRA help your native application?

[alexgvozden]

@tbillington you are absolutely right, this is my mistake
best address for this is react-native-cli :)
sorry for an opinionated discussion