Google Closure Tools

The Closure Compiler is a tool for making JavaScript download and run faster. It is a true compiler for JavaScript. Instead of compiling from a source language to machine code, it compiles from JavaScript to better JavaScript. It parses your JavaScript, analyzes it, removes dead code and rewrites and minimizes what's left. It also checks syntax, variable references, and types, and warns about common JavaScript pitfalls. 1. Compilation modes other than ADVANCED were always an afterthought and we have deprecated those modes. We believe that other tools perform comparably for non- ADVANCED modes and are better integrated into the broader JS ecosystem. 1. Closure Compiler is not suitable for arbitrary JavaScript. For ADVANCED mode to generate working JavaScript, the input JS code must be written with closure-compiler in mind. Although one can write custom externs files to tell the compiler to leave some names unchanged so they can safely be accessed by code that is not part of the compilation, this is often tedious to maintain. 1. Closure Compiler property renaming requires you to consistently access a property with either obj[p] or obj.propName , but not both. When you access a property with square brackets (e.g. obj[p] ) or using some other indirect method like let {p} = obj; this hides the literal name of the property being referenced from the compiler. It cannot know if obj.propName is referring to the same property as obj[p] . In some cases it will notice this problem and stop the compilation with an error. In other cases it will rename propName to something shorter, without noticing this problem, resulting in broken output JS code. 1. Closure Compiler aggressively inlines global variables and flattens chains of property names on global variables (e.g. myFoo.some.sub.property - myFoo$some$sub$property ), to make reasoning about them easier for detecting unused code. It tries to either back off from doing this or halt with an error when doing it will generate broken JS output, but there are cases where it will fail to recognize the problem and simply generate broken JS without warning. This is much more likely to happen in code that was not explicitly written with Closure Compiler in mind. 1. Closure compiler and the externs it uses by default assume that the target environment is a web browser window. WebWorkers are supported also, but the compiler will likely fail to warn you if you try to use features that aren't actually available to a WebWorker. Some externs files and features have been added to Closure Compiler to support the NodeJS environment, but they are not actively supported and never worked very well. 1. JavaScript that does not use the goog.module() and goog.require() from base.js to declare and use modules is not well supported. The ECMAScript import and export syntax did not exist until 2015. Closure compiler and closure-library developed their own means for declaring and using modules, and this remains the only well supported way of defining modules. The compiler does implement some understanding of ECMAScript modules, but changing Google's projects to use the newer syntax has never offered a benefit that was worth the cost of the change. Google's TypeScript code uses ECMAScript modules, but they are converted to goog.module() syntax before closure-compiler sees them. So, effectively the ECMAScript modules support is unused within Google. This means we are unlikely to notice or fix bugs in the support for ECMAScript modules. Check the JS code for errors and for conformance to general and/or project-specific best practices. Transpile newer JS features into a form that will run on browsers that lack support for those features. Break the output application into chunks that may be individually loaded as needed. NOTE: These chunks are plain JavaScript scripts. They do not use the ECMAScript import and export syntax. Support for the import and export syntax added in ES6 is not actively maintained.