Related
I'm developping a JS-app that needs to work both on the client side and the server side (in Javascript on a browser and in Node.js), and I would like to be able to reuse the parts of the code that are used for both sides.
I have found out that window was a variable only accessible on Browsers, and global in node, so I can detect in which environment the code is executing (assuming that no script declares the window variable)
They are two problems.
How should I detect in which browser the code is running. For example, is this code OK. (This code is inline, meaning that it is surrounded by some global code, reused for both environments)
if window?
totalPath= "../examples/#{path}"
else
totalPath= "../../examples/#{path}"
How can I use global variables for both environments ? Now, I'm doing the following, but this really doesn't feel right.
if window?
window.DocUtils = {}
window.docX = []
window.docXData= []
else
global.DocUtils= {}
global.docX = []
global.docXData = []
NOTE: This question had two parts, but because the title was "Environment detection: node.js or browser" - I will get to this part first, because I guess many people are coming here to look for an answer to that. A separate question might be in order.
In JavaScript variables can be redefined by the inner scopes, thus assuming that environment has not created variables named as process, global or window could easily fail, for example if one is using node.js jsdom module, the API usage example has
var window = doc.defaultView;
After which detecting the environment based on the existence of window variable would systematically fail by any module running under that scope. With the same logic any browser based code could easily overwrite global or process, because they are not reserved variables in that environment.
Fortunately there is a way of requiring the global scope and testing what it is - if you create a new function using a new Function() constructor, the execution scope of this is bound to the global scope and you can compare the global scope directly to the expected value. *)
So to create a function check if the global scope is "window" would be
var isBrowser=new Function("try {return this===window;}catch(e){ return false;}");
// tests if global scope is bound to window
if(isBrowser()) console.log("running under browser");
And function to test if global scope is bound to "global" would be
var isNode=new Function("try {return this===global;}catch(e){return false;}");
// tests if global scope is bound to "global"
if(isNode()) console.log("running under node.js");
the try... catch -part will makes sure that if variable is not defined, false is returned.
The isNode()could also compare this.process.title==="node" or some other global scope variable found inside node.js if you will, but comparing to the global should be enough in practice.
http://jsfiddle.net/p6yedbqk/
NOTE: detecting the running environment is not recommended. However, it can be useful in a specific environment, like development and testing environment which has some known characteristics for the global scope.
Now - the second part of the answer. after the environment detection has been done, you can select which environment based strategy you want to use (if any) to bind your variable which are "global" to your application.
The recommended strategy here, in my opinion, would be to use a singleton pattern to bind your settings inside a class. There is a good list of alternatives already in SO
Simplest/cleanest way to implement a singleton in JavaScript
So, it may turn out if you do not need a "global" variable, and you do not need the environment detection at all, just use the singleton pattern to defined a module, which will store the values for you. OK, one can argue that the module itself is a global variable, which in JavaScript it actually is, but at least in theory it looks a bit cleaner way of doing it.
*) https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function
Note: Functions created with the Function constructor do not create
closures to their creation contexts; they always are created in the
global scope. When running them, they will only be able to access
their own local variables and global ones, not the ones from the scope
in which the Function constructor was called.
Since apparently Node.js could have both (w/ NW.js?), my personnal way to do it is by detecting if the node entry exists in process.versions object.
var isNode = false;
if (typeof process === 'object') {
if (typeof process.versions === 'object') {
if (typeof process.versions.node !== 'undefined') {
isNode = true;
}
}
}
The multilevel of conditions is to avoid errors while searching into an undefined variable due to some browsers limitations.
Reference: https://nodejs.org/api/process.html#process_process_versions
There is an npm package just for this and it can be used both on client-side and server-side.
browser-or-node
You can use it this way
if (isBrowser) {
// do browser only stuff
}
if (isNode) {
// do node.js only stuff
}
Disclaimer: I am the author of this package :)
You can attach to variable window or global - based on situation. Though it is not a recommended way of making multi-platform JS application:
var app = window ? window : global;
It is much better to have your global variable, that will be used over logic of application, but will be made of parts of based on different platforms. Something like:
var app = {
env: '',
agent: ''
};
if (window) {
app.env = 'browser';
app.agent = navigator.userAgent;
} else if (process) {
app.env = 'node';
}
So the idea is that your main application logic will be absolutely the same and will use same object, only that global object have to be changed based on environment. That makes your application much more portable and flexible in terms of platforms.
I know this is a late answer to a (1.5 year) old question but why not copy jQuery's source code?
if (typeof module === "object" && typeof module.exports === "object") {
// node
}
if (typeof window !== "undefined" && typeof window.document !== "undefined") {
// browser
}
Good luck.
this seems to work well regardless of scope unless you've named something else window
const isBrowser = () => typeof window !== `undefined`
if (isBrowser())
console.log(`is browser`)
else
console.log(`is node.js`)
/*
detect global/window/self in browser, deno, nodejs
including where 'this' is undefined
*/
const self = new Function('return this')(); // be careful, Function is like eval, use with caution
console.log(
(self.window && "window" || self.global && 'global'),
self.toString().slice('[object '.length, -1).toLowerCase()
);
/*
browser: window window
nodejs: global global
deno: window object
*/
Old question with many complicated answers, even an npm package, but this solution is quite simple and robust, unless sabotaged on purpose (no solution is 100% precise BTW, because you can set global variables on both environments)
if (typeof process === 'object' && String(process) === '[object process]') {
// is Node
} else {
// is Browser
}
Normally (almost always) scripts which run on browsers don't have the global process object, and even if you create one by accident with process = {}, it will fail in the second condition.
I am not totally familiar with the Node environment and all its situations such as when Babel or WebPack is being used. But this is one way if you have code that runs in the browser vs in the Node console:
if (this.window) {
// inside browser
} else {
// inside Node
}
Simple condition from pdf.js
Second condition variant process.constructor.name === 'process'
src/shared/is_node.js:
/* Copyright 2018 Mozilla Foundation
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
/* globals process */
// NW.js / Electron is a browser context, but copies some Node.js objects; see
// http://docs.nwjs.io/en/latest/For%20Users/Advanced/JavaScript%20Contexts%20in%20NW.js/#access-nodejs-and-nwjs-api-in-browser-context
// https://www.electronjs.org/docs/api/process#processversionselectron-readonly
// https://www.electronjs.org/docs/api/process#processtype-readonly
const isNodeJS =
typeof process === "object" &&
process + "" === "[object process]" &&
!process.versions.nw &&
!(process.versions.electron && process.type && process.type !== "browser");
export { isNodeJS };
This is what I'm using based on #TeroTolonen answer:
var isBrowser = (function() {
try {
return this === window;
} catch (e) {
return false;
}
})();
if (isBrowser) {
}
There is no need for a function constructor and you can call it once.
"tl;dr" included
When trying to disable Logging so as to avoid spam once deploying, I used to do something like
if (isDebug)
console.log(...);
but I felt like (or read online) this would slow the code overall because the condition would be evaluated each time (and I usually include a lot of these, and the functions are called often, either via loops, setIntervals or w/e).
As such, I now switched to simply "emptying" the functions using a custom logger like
function LOGGER_MODULE_FACTORY() {
let current_log_level = "log";
return {
log: console.log,
info: console.info,
warn: console.warn,
error: console.error,
setDebug: function(logLevel) {
current_log_level = logLevel;
this.log = (logLevel === true || logLevel === "log") ? console.log : function () {};
this.info = (logLevel === true || logLevel === "log" || logLevel === "info") ? console.info : function () {};
this.warn = (logLevel === true || logLevel === "log" || logLevel === "info" || logLevel === "warn") ? console.warn : function () {};
this.error = (!logLevel) ? function () {} : console.error;
return logLevel;
},
getCurrent_log_level: function () { return current_log_level; }
}
}
Thinking that it would probably be quicker to run an empty function than evaluating an expression and it felt cleaner to write.
I tried creating a fiddle to test my theory and compare performance but the values are often pretty random...
Edit: jsperf test
Interesting results. "Chrome 64" 's results are from running in on Edge.
My reasoning relied on the fact that I read few things about CPUs and, apparently, they do things on their own in order to optimize the general run-time like, for instance, skipping useless operations: Say we have :
a = x
b = y
c = a + 3
The CPU would actually ignore the second line (or something... I am far from being an expert ahah, I just curiously read that fact).
Now, since we, on our browser, may access any globally declared variable at some point using the console, this cannot happen and so I felt I should simply ask online :
tl;dr:
Is calling an empty/bodiless function repeatedly (the pages I create basically run 24/7 on a dashboard) better, performance-wise than placing a condition in front of the original function (console.log / info / warn / error) ?
Basically, you are asking which is faster f = () => {}; f() or flag = false; if (flag) f()
isDebug won't be evaluated at every execution, but the stored variable will just be read.
It would be different if it was if (isDebug()), in this case, every time the parser meets the statement, the function will be evaluated.
Obviously, reading the isDebug boolean variable will add some overhead, but this is not perceptible since reading and handling variable is the main purpose of a programming language, so the time required for reading a boolean will always be lower than any other statement in the code.
Reassigning the console.log function is not a bad idea, it could be useful for enabling or disabling the logs all in one point. But this is a solution for a different problem
I am working on project that uses quite a few js libraries and one of them is outputting awful lot into console, it is polluting the airwaves so bad that it makes it hard to debug....
I know how to disable logging completely by overriding console.log with this,
(function (original) {
console.enableLogging = function () {
console.log = original;
};
console.disableLogging = function () {
console.log = function () {};
};
})(console.log);
but how do it do that per source(file/url) of where message originated?
Preamble
The beginning discusses how stuff works in general. If you just care for the code, skip Introduction and scroll to the Solution heading.
Introduction
Problem:
there is a lot of console noise in a web application. A significant amount of that noise is coming from third party code which we do not have access to. Some of the log noise might be coming from our code, as well.
Requirement:
reduce the noise by stopping the log. Some logs should still be kept and the decision about those should be decoupled from the code that is doing the logging. The granularity needed is "per-file". We should be able to choose which files do or do not add log messages. Finally, this will not be used in production code.
Assumption: this will be ran in a developer controlled browser. In that case, I will not focus on backwards compatibility.
Prior work:
First off logging can be enabled/disabled globally using this
(function (original) {
console.enableLogging = function () {
console.log = original;
};
console.disableLogging = function () {
console.log = function () {};
};
})(console.log);
(code posted in the question but also here for reference)
However, that does not allow for any granularity.
This could be modified to work on only specific modules but that cannot be done for third party code.
A mixed approach would be to disable logging globally but enable it in each of our modules. Problem there is that we have to modify each of our files and we will not get some potentially useful external messages.
A logging framework can be used but it might be an overkill. Although, to be honest, that's what I'd go for, I think, but it may need some integration into the product.
So, we need something light-weight-ish that has some configuration and does not need to be pretty.
Proposal:
The Loginator (title subject to change)
Let's start with the basics - we already know we can override the global log function. We'll take that and work with it. But first, let's recognise that the console object supports more than just .log. There could be various logging functions used. So-o-o, let's disable all of them.
Silence everything
//shorthand for further code.
function noop() {}
const savedFunctions = Object.keys(console)
.reduce((memo, key) => {
if(typeof console[key] == "function") {
//keep a copy just in case we need it
memo[key] = console[key];
//de-fang any functions
console[key] = noop;
}
return memo;
},
{});
console.log("Hello?");
console.info("Hello-o-o-o?");
console.warn("Can anybody hear me?");
console.error("I guess there is nobody there...");
savedFunctions.log("MUAHAHAHA!")
This can obviously be improved but it showcases how any and ll logging can be stopped. In reality, console.error should probably be left and console.warn might be also useful. But this is not the be-all-and-end-all solution.
Next, since we can override console functionality...why not supply our own?
Custom logging
const originalLog = console.log;
console.log = function selectiveHearing() {
if (arguments[0].indexOf("die") !== -1) {
arguments[0] = "Have a nice day!";
}
return originalLog.apply(console, arguments)
}
console.log("Hello.");
console.log("My name is Inigo Montoya.");
console.log("You killed my father.");
console.log("Prepare to die.");
That is all the tools we need to roll our own mini-logging framework.
How to do selective logging
The only thing missing is to determine which file something is coming from. We just need a stack trace.
// The magic
console.log(new Error().stack);
/* SAMPLE:
Error
at Object.module.exports.request (/home/vagrant/src/kumascript/lib/kumascript/caching.js:366:17)
at attempt (/home/vagrant/src/kumascript/lib/kumascript/loaders.js:180:24)
at ks_utils.Class.get (/home/vagrant/src/kumascript/lib/kumascript/loaders.js:194:9)
at /home/vagrant/src/kumascript/lib/kumascript/macros.js:282:24
at /home/vagrant/src/kumascript/node_modules/async/lib/async.js:118:13
at Array.forEach (native)
at _each (/home/vagrant/src/kumascript/node_modules/async/lib/async.js:39:24)
at Object.async.each (/home/vagrant/src/kumascript/node_modules/async/lib/async.js:117:9)
at ks_utils.Class.reloadTemplates (/home/vagrant/src/kumascript/lib/kumascript/macros.js:281:19)
at ks_utils.Class.process (/home/vagrant/src/kumascript/lib/kumascript/macros.js:217:15)
*/
(Relevant bit copied here.)
True, there are some better ways to do it but not a lot. It would either require a framework or it's browser specific - error stacks are not officially supported but they work in Chrome, Edge, and Firefox. Also, come on - it's literally one line - we want simple and don't mind dirty, so I'm happy for the tradeoff.
Solution
Putting it all together. Warning: Do NOT use this in production
(function(whitelist = [], functionsToPreserve = ["error"]) {
function noop() {}
//ensure we KNOW that there is a log function here, just in case
const savedFunctions = { log: console.log }
//proceed with nuking the rest of the chattiness away
Object.keys(console)
.reduce((memo, key) => {
if(typeof console[key] == "function" && functionsToPreserve.indexOf(key) != -1 ) {
memo[key] = console[key];
console[key] = noop;
}
return memo;
},
savedFunctions); //<- it's a const so we can't re-assign it. Besides, we don't need to, if we use it as a seed for reduce()
console.log = function customLog() {
//index 0 - the error message
//index 1 - this function
//index 2 - the calling function, i.e., the actual one that did console.log()
const callingFile = new Error().stack.split("\n")[2];
if (whitelist.some(entry => callingFile.includes(entry))) {
savedFunctions.log.apply(console, arguments)
}
}
})(["myFile.js"]) //hey, it's SOMEWHAT configurable
Or a blacklist
(function(blacklist = [], functionsToPreserve = ["error"]) {
function noop() {}
//ensure we KNOW that there is a log function here, just in case
const savedFunctions = {
log: console.log
}
//proceed with nuking the rest of the chattiness away
Object.keys(console)
.reduce((memo, key) => {
if (typeof console[key] == "function" && functionsToPreserve.indexOf(key) != -1) {
memo[key] = console[key];
console[key] = noop;
}
return memo;
},
savedFunctions); //<- it's a const so we can't re-assign it. Besides, we don't need to, if we use it as a seed for reduce()
console.log = function customLog() {
//index 0 - the error message
//index 1 - this function
//index 2 - the calling function, i.e., the actual one that did console.log()
const callingFile = new Error().stack.split("\n")[2];
if (blacklist.some(entry => callingFile.includes(entry))) {
return;
} else {
savedFunctions.log.apply(console, arguments);
}
}
})(["myFile.js"])
So, this is a custom logger. Sure, it's not perfect but it will do the job. And, hey, since the whitelisting is a bit loose, it could be turned to an advantage:
to whitelist a bunch of files that share a substring, say, all myApp can include myApp1.js, myApp2.js, and myApp3.js.
although if you want specific files, you can just pass the full name, including extension. I doubt there would be a bunch of duplicate filenames.
finally, the stack trace will include the name of the calling function, if any, so you can actually just pass that and that will whitelist on per-function basis. However, it relies on the function having a name and it's more likely for function names to clash, so use with care
Other than that, there can certainly be improvements but that is the basis of it. The info/warn methods can also be overriden, for example.
So, this, if used, should only be in dev builds. There are a lot of ways to make it not go into production, so I won't discuss them but here is one thing I can mention: you can also use this anywhere if you save it as a bookmarklet
javascript:!function(){function c(){}var a=arguments.length<=0||void 0===arguments[0]?[]:arguments[0],b=arguments.length<=1||void 0===arguments[1]?["error"]:arguments[1],d={log:console.log};Object.keys(console).reduce(function(a,d){return"function"==typeof console[d]&&b.indexOf(d)!=-1&&(a[d]=console[d],console[d]=c),a},d),console.log=function(){var c=(new Error).stack.split("\n")[2];a.some(function(a){return c.includes(a)})&&d.log.apply(console,arguments)}}(["myFile.js"]);
This is it minified (although I passed it through Babel first, to use ES5 minification) and still configurable, to an extent, as you can change the very end where you can pass the whitelist. But other than that, it will work the same and is completely decoupled from the codebase. It will not run at pageload but if that's needed you can either use this as a userscript (still decoupled) or include it before other JS files in dev/debug builds only.
A note here - this will work in Chrome, Edge and Firefox. It's all the latest browsers, so I assume a developer will use at least one of them. The question is tagged as Chrome but I decided to widen the support. A Chrome only solution could work slightly better but it's not really a big loss of functionality.
I was as troubled as you. This is my approach. https://github.com/jchnxu/guard-with-debug
Simple usage:
localStorage.debug = [
'enable/console/log/in/this/file.ts',
'enable/console/log/in/this/folder/*',
'-disable/console/log/in/this/file.ts',
'-disable/console/log/in/this/folder/*',
// enable all
'*',
].join(',');
The benefit: it's zero-runtime.
Disclaimer: I am the author of this tiny utility
It work in chrome:
...index.html
<html>
<body>
<script>
(function(){
var original = console.log;
console.log = function(){
var script = document.currentScript;
alert(script.src);
if(script.src === 'file:///C:/Users/degr/Desktop/script.js') {
original.apply(console, arguments)
}
}
})();
console.log('this will be hidden');
</script>
<script src="script.js"></script>
</body>
</html>
...script.js
console.log('this will work');
Console.log does not work from index.html, but work from script.js. Both files situated on my desctop.
I've found these settings in the latest (July 2020) Chrome DevTools console to be helpful:
DevTools | Console | (sidebar icon) | user messages
DevTools | Console | (gear icon) | Select context only
DevTools | Console | (gear icon) | Hide network
I like (1) most, I only see the messages from "my" code. (2) hides messages from my iframe.
If it's an option to modify file, you can set a flag at top of file for disabling logs for that:
var DEBUG = false;
DEBUG && console.log("cyberpunk 2077");
To disable logs for all js files, put it once at top of any js file:
var DEBUG = false;
if (!DEBUG) {
console.log = () => {};
}
This is not pretty but will work.
Put something like this in your file before the <script> tag of the "bad" library :
<script>function GetFile(JSFile) {
var MReq = new XMLHttpRequest();
MReq.open('GET', JSFile, false);
MReq.send();
eval(MReq.responseText.replace(/console.log\(/g,"(function(){})("));
}</script>
Then replace the tag
<script src="badLib.js">
With:
GetFile("badLib.js")
Only for short time debugging.
I've followed the advice from this other SO thread to remove console.log() statements from my code.
Unfortunately, now Closure compiler is removing my entire code and not just the console.log() statements.
Might someone explain this? I'm at a loss...
JS file 1
(function(){
/** #const */
LOG = false;
function log() {
return console.log.apply(console, arguments);
}
LOG && log('hello world !');
var foo='bar';
LOG && log("foo"+foo);
})();
JS file 2
(function(){
/** #const */
LOG = false;
function test(){
alert('testing...');
}
var baz='bazzy';
LOG && log("baz"+baz);
})();
Closure compiler step:
$ java -jar compiler-latest/compiler.jar --js j1.js j2.js --js_output_file compiled.js
Result:
(function(){LOG=!1})();(function(){LOG=!1})();
Because the compiler determines that the rest of your code is unreachable.
Both files have a constant LOG set to false and you are not exporting anything (goog.export* or window['...'] = ...).
The code which could get executed has a LOG && in front of it, which means it is not executed.
Therefor nothing can get executed, and thus the compiler removes it all.
Why is function test remoed: nobody calls it, simple as that. Call it in one of your files, and the compiler won't strip it away.
You can (should, actually) define LOG and log only in one file.
For that to work, remove the anonymous function call around your code in every file.
You can tell the compiler to add it back to the compiled code with the commandline option:
--output_wrapper=(function(){ %output% })();
So your two files should look like this:
JS file 1
/** #const */
var LOG = false;
function log() {
return console.log.apply(console, arguments);
}
LOG && log('hello world !');
var foo='bar';
LOG && log("foo"+foo);
JS file 2
function test(){
alert('testing...');
}
var baz='bazzy';
LOG && log("baz"+baz);
// call test, so it a) isnt stripped and b) well, executed :)
test();
Also, you might want to put your global vars and functions into a "namespace" to not pollute the global scope:
// create namespace (which is just a normal object)
var MyNamespace = {};
// create a namespaced function
MyNamespace.test = function() {
alert('test');
}
// call it
MyNamespace.test();
I'm looking for a way to strip out debug code from functions so I can add test hooks to closures. I've read
Google Closure Compiler advanced: remove code blocks at compile time and tested out removing debug code with the following:
/** #define {boolean} */
var DEBUG = true;
if (DEBUG) {
console.log('remove me');
}
Simple optimisation with --define='DEBUG=false' reduces this to var DEBUG=!1;. The same applies for this:
/** #const */
var DEBUG = false;
if (DEBUG) {
console.log('remove me');
}
Where I run into trouble is using this convention inside a function:
/** #const */
var DEBUG = false;
function logMe() {
if (DEBUG) {
console.log('remove me');
}
}
This reduces to the following:
var DEBUG=!1;function logMe(){DEBUG&&console.log("remove me")};
I would expect it to reduce further to:
var DEBUG=!1;function logMe(){};
Is there a reason this is not working as expected? I'm really just looking for a clean way to strip debug code and am not ready to take the plunge into advanced optimizations.
Update
Per #John's answer, I implemented my own compiler and have found that the following configuration will remove if (DEBUG) {} from inside and outside the code for the case of a #define:
CompilerOptions options = new CompilerOptions();
CompilationLevel.SIMPLE_OPTIMIZATIONS.setOptionsForCompilationLevel(options);
//options.setInlineConstantVars(true);
options.setInlineVariables(CompilerOptions.Reach.ALL);
options.setDefineToBooleanLiteral("DEBUG", false);
This works well enough for a single file with the following limitations:
This requires var DEBUG to be defined in each file, which is bad practice.
When combining multiple files, you can only have a single var DEBUG or the compiler can't optimize around it. This could be avoided by compiling each file individually and merging them.
Because the value is defined at the beginning of the file, there's no flexibility to receive the value beforehand.
I've toyed with the idea of removing all var DEBUG definitions from the files and injecting it into the source or extern before execution, but I've run into two issues:
Defining it in extern appears to do nothing.
Undefined DEBUG in the uncompiled code throws a reference error in the browser.
The ideal option would be to test window.DEBUG, which does not throw a reference error. Unfortunately, while injecting /** #const */ var window = {}; /** #const */ window.DEBUG = false; works at the top level, reducing if (window.DEBUG) {}, the optimization is actually reverted if placed in a function.
Unless another compiler option works the only option that would really make sense is to go with window.DEBUG and before compilation inject /** #const */ var DEBUG = false; and to a global replace of /\bwindow.DEBUG\b/ with DEBUG. Is there a better way?
Use #define annotation:
#define {boolean}
DEBUG = true;
And compile with option
--define="DEBUG=false"
A custom build of the compiler would allow you to do this. You basically want to "inline constant variables":
options.setInlineConstantVars(true);
You could add it here, in applySafeCompilationOptions:
http://code.google.com/p/closure-compiler/source/browse/trunk/src/com/google/javascript/jscomp/CompilationLevel.java?r=706
Or you could use the Java API and add the option (without modifying the compiler's code). Michael Bolin given an example of how to do this here:
http://blog.bolinfest.com/2009/11/calling-closure-compiler-from-java.html
This is an old answer, but I found a way that's not mentioned here.
(function(){
var DEBUG = true;
if (DEBUG) {
if (something === "wrong") {
console.warn("Stop! Hammer time!");
}
else if (something === "as expected") {
console.log("All good :-)");
}
}
foo();
})();
With ADVANCED_OPTIMIZATIONS this compiles to this:
"wrong" === something ?
console.warn("Stop! Hammer time!") :
"as expected" === something && console.log("All good :-)");
foo();
In our build script we can rewrite the DEBUG line to set it to false, which would then yield this output.
foo();
The reason this happens is Closure will remove unreachable code. By creating the closure, and defining a local variable, Closure can see that we can't do something like window.DEBUG === true, so the code is guaranteed to never be run.
Your DEBUG variable is currently global. GCC will not remove or rename global variables in simple optimization mode, so they'll remain available to any code in other scripts that might possibly want to access them. Try enclosing your code into anonymous function.
The way i solved the problem of "removing debug functions from closure compiled javascript using SIMPLE_OPTIMIZATION" was by combining a similar method as #John proposes as well as using some of #Brian Nichols update. I could only get the compiler to remove the lines by placing this is the global scope of my main js file and doing a custom compile (using multiple .js files this still removed them)
/** #const
* #type {boolean}
*/
var DEBUG = false;
//and used this format for my debug function
DEBUG && myLog('foo');
and then compiling the closure-compiler java with ant to include this option options.setInlineVariables(CompilerOptions.Reach.ALL);
under the applySafeCompilationOptions function in the CompilationLevel.java file as #john suggests. This worked for me and didnt break my codebase as ADVANCED did...
Remove var DEBUG = true; from your code and convert all your conditions that check if (DEBUG) to if (goog.DEBUG). Modify your compiler option to read --define goog.DEBUG=false. The goog variable is built into the Closure Library API to provide options and flags for the compiler.