I have tons of console.log-calls in my code which is useful in the development, but something I wouldn't want to push to the console for end users.
I think it would be great to be able to config an environment something like this:
export const environment = {
production: true,
remove_console_log: true,
remove_console_warning: true
};
This would build for production and simply remove console.log- and console.warning-calls while keeping console.error. Perhaps even "remove_debugger" (debugger;) and "remove_alert" (alert()) could be added.
I'm not sure if it's allowed to post suggestions/requests here, if not you're may just delete the post.
Just create a wrapper function on top of console functions, and use it. For example
log(...args) {
if (!production) {
console.log.apply(console, args);
}
}
Our environment file functionality just allows you to conditionally replace a file import with another file. We don't really process or interpret it.
My suggestion for your scenario is to use ng lint
instead, and configure tslint.json
to not allow console.log
statements: http://palantir.github.io/tslint/rules/no-console/~~
I'm sorry, I misunderstood the usecase and offered a bad suggestion. A better suggestion would be to use a logger service that wraps console.log
and checks the environment, similar to what is suggested in the comment above.
@filipesilva
my tslint.json:
"no-console": [
true,
"log",
"debug",
"info",
"time",
"timeEnd",
"trace"
],
I then build my app via ng build --prod
My app still contains all my console calls
what are the missing configuration settings and/or steps to take so that ng build --prod
removes console
There are various clues scattered about stackoverflow, (such as http://stackoverflow.com/a/43123545/1371433), but no full walkthrough for getting this to work via angular-cli. ie is npm run build
the same as running ng build
?
An other option would be to usewebpack
. You can generate the config by hitting: ng eject
And the use the loader webpack-strip
https://www.npmjs.com/package/webpack-strip
Hope it helps!
@janjachacz I think you should mention that once ejected there is no turning back.
@kwalski, you can just move the "ejected": true
in .angular-cli.json
.
Hi @Axure - can you clarify? Maybe you mean:
you can just toggle the
"ejected": true
in.angular-cli.json
I assume you're saying there is a way to "turn back"?
@filipesilva Horrible suggestion to use ng lint
On the use of logger service, take a look at smart-console. You can set-up environment variables and pass it to the service and control logs per your environment.
Am I single person who thinks that wrapper function or setting to an empty function are bad solutions?
If I don't want to show something in console why do I need it to be presented in a bundle?
I know it's a tiny amount of kilobytes and runtime milliseconds but it's just wrong to me.
Stripping console log was possible for grunt, gulp, webpack, I don't get why not letting users to choose if they want to strip it from bundle code or not.
Although you have a valid point of view, if your application and your policy decides that there should be absolutely no logs what so ever; then you can strip out logs when trans-piling the code. However, if you are in need of letting some logs to go through under special circumstances, then you will have two options, 1) create a service and call it's methods instead of console to receive your "logs" and decide what has to be done about it. 2) write a service that takes over the console logs and does the same thing provided in option one.
But option one has a flaw. it will throttle only the logs you have in place in your code. You will not be able to control them as well which will bring you to the second option.
On the use of logger service, take a look at smart-console. You can set-up environment variables and pass it to the service and control logs per your environment.
One thing about the smart-console is that if you pass in an instance of options to makeSmartLogs() method and later on change attributes of that instance, then you can effectively control throttling of logs per special circumstances any time.
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
_This action has been performed automatically by a bot._
Most helpful comment
@janjachacz I think you should mention that once ejected there is no turning back.