New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
strip console.* in dist/flow.min.js #312
Conversation
I don't think adding console.log to the lib is a good practice. It just means that code is clunky and it needs to be refactored instead. |
Many software, even those not involving complex chunking and concurrency heuristic, end-up with some logging facilities (including a debugging level). Even a low-level graphic library like GDK for Gnome offer advanced debuging via environment variable, available in their -production build on the end-user desktop. Indeed we could as well write a The toolchain offers a chance of creating both good -production and very convenient -debug builds. |
Maybe more versatile solution would be to add Flow.log function. E.g.: log: function (message) {
if (this.opts.log) {
console.log(message);
}
} And usage would be: Though it should be disabled by default. |
But don't you think that all occurrences of |
I don't think they need to be stripped if they are disabled by a variable by default. Package size is going to be the same anyway. |
@evilaliv3 : Any opinion? |
I gave a thought about these logs during my sleep and I have an elegant idea. Why not to make it an event?
|
Pro:
Cons:
Personally I still like the idea of just stripping I previously gave an argument that production software builds containing debugging facility actionable at runtime. |
I must disagree. Striping console.log from the build is harder than just remove it from the hook. From my point of view, console log messages should be left with deprecation messages and errors. These are a serious messages and they will never appear in the console once fixed. This this pull request we are going to remove these messages as well, which I would like to avoid. Every other informational/debug console.log should be done via Other libraries does that too and this way my console stays clean. I only want to see these messages if I am debugging this library. After it's implemented I want to focus on the other stuff and these messages does nothing more than distract. |
In the particular case of this PR (which was mostly to discuss the idea rather than a perfect implementation), it would have only stripped |
let's keep this going, better something than nothing. You can merge this |
db403b6
to
cafa2c7
Compare
Addressing a comment from #304
I suggest either:
console.*
from one of the bundle (.js or .min.js) so that the other can be used during test (and still show the output)Keeping
console.log
accelerates development and it sounds better to leave to the toolchain the job of striping them when needed.