closure-compiler:minify

By default, when the output file is the same as the input file, compilation is terminated with an error. This is done to prevent source files from being overwritten accidentally with a bad configuration. If you are certain you want to replace the input files (such as when the input files themselves are temporary files that have been generated), set this option to true. Defaults to false.

Note: When enabling this option, you might also want to set skipMerge to true and the outputFilename to #{path}/#{basename}.#{extension}.

Base directory relative to which the htmlFiles to process are evaluated, see the option htmlUpdates. Relative paths are evaluated relative to the project's base directory.

The root directory of the HTML files, see the option htmlUpdates. Used to construct a relative path from the HTML file the script file.

Relative paths are resolved against the project's base directory.

For example, assume the following configuration:

• HTML file - /home/user/project/src/main/resources/webapp/public/pages/profile/index.html
• Script file - /home/user/project/target/generated-resources/frontend/js/public/resources/main/script.min.js
• HTML root - /home/user/project/src/main/resources/webapp
• Script root - /home/user/project/target/generated-resources/frontend/js

Then, the relative path of the HTML file relative to the HTML root is public/pages/profile/index.html and the relative of the JavaScript file is public/resources/main/script.min.js.

Finally, the script file is relativized against the HTML file; and the final relative path used to update the script tag in the HTML file is ../../resources/main/script.min.js

Precedence: htmlSourcePath has the highest priority. htmlUsePhysicalRoot comes next, htmlRoot and htmlScriptRoot have the lowest priority.

The root directory of the script files, see the option htmlUpdates. Used to construct a relative path from the HTML file the script file.

Relative paths are resolved against the project's base directory.

For example, assume the following configuration:

• HTML file - /home/user/project/src/main/resources/webapp/public/pages/profile/index.html
• Script file - /home/user/project/target/generated-resources/frontend/js/public/resources/main/script.min.js
• HTML root - /home/user/project/src/main/resources/webapp
• Script root - /home/user/project/target/generated-resources/frontend/js

Then, the relative path of the HTML file relative to the HTML root is public/pages/profile/index.html and the relative of the JavaScript file is public/resources/main/script.min.js.

Finally, the script file is relativized against the HTML file; and the final relative path used to update the script tag in the HTML file is ../../resources/main/script.min.js

Precedence: htmlSourcePath has the highest priority. htmlUsePhysicalRoot comes next, htmlRoot and htmlScriptRoot have the lowest priority.

Base directory for source files. This should be an absolute path; if not, it must be relative to the project base directory. Use variables such as basedir to make it relative to the current directory.

Base directory for output files. This should be an absolute path; if not, it must be relative to the project base directory. Use variables such as project.build.directory to make it relative to the current directory.

Size of the buffer used to read source files.

Specify aggregations in an external JSON formatted config file. If not an absolute path, it must be relative to the project base directory.

Enables experimental support for allowing dynamic import expressions import('./path') to pass through the compiler unchanged. Enabling this requires setting closureLanguageOut to at least ECMASCRIPT_2020.

Generate $inject properties for AngularJS for functions annotated with @ngInject.

Enable additional optimizations based on the assumption that the output will be wrapped with a function wrapper. This flag is used to indicate that "global" declarations will not actually be global but instead isolated to the compilation unit. This enables additional optimizations.

Regardless of input type, the compiler will normalize all files and bundle them together. By default, a single output file is produced. However, this may not work for you if your application is big. In that case, you may want to have the compiler break your code up into multiple chunks that can be loaded separately. You will design your application so that the code you always need gets loaded in an initial chunk, probably from a <script> tag, then that chunk will load others (which may load still others) as needed in order to support the user's actions. (e.g. The user may request a new display view, which requires you to load the code for showing that view.)

• GLOBAL_NAMESPACE (Chunks as Scripts using a Global Namespace): This is the default option and the compiler will produce standard scripts. This mode is normally paired with the closureOutputWrapper flag for script isolation and the closureRenamePrefixNamespace flag so that symbols can be referenced across chunks.
• ES_MODULES (Chunks as EcmaScript modules): The compiler will output es modules and cross chunk references will utilize the import and export statements. Since modules have built in isolation and modern browsers know how to load them, this option is by far the easiest.

Whether the error output from the closure compiler is colorized. Color codes may not be supported by all terminals.

The degree of compression and optimization to apply to your JavaScript.
There are three possible compilation levels:

• WHITESPACE_ONLY: Just removes whitespace and comments from your JavaScript.
• SIMPLE_OPTIMIZATIONS: Performs compression and optimization that does not interfere with the interaction between the compiled JavaScript and other JavaScript. This level renames only local variables.
• ADVANCED_OPTIMIZATIONS: Achieves the highest level of compression by renaming symbols in your JavaScript. When using ADVANCED_OPTIMIZATIONS compilation you must perform extra steps to preserve references to external symbols. See Advanced Compilation and Externs for more information about ADVANCED_OPTIMIZATIONS.
• BUNDLE: Leaves all compiler options unchanged. For advanced usage if you want to set the relevant options yourself.

Collects information mapping the generated (compiled) source back to its original source for debugging purposes.

Enable debugging options. Property renaming uses long mangled names which can be mapped back to the original name.

Override the value of variables annotated with @define.
The format is:

<define>
    <name>value</name>
</define>

where <name> is the name of a @define variable and value is a JavaScript boolean, number or string literal. That is, use quotation marks to specify a string: "First line\nseconds line"

When you use closureDependencyMode PRUNE or PRUNE_LEGACY, you must specify to the compiler what the entry points of your application are. Beginning at those entry points, it will trace through the files to discover what sources are actually referenced and will drop all other files.

Adds a collection of symbols to always keep. In dependency pruning mode, we will automatically keep all the transitive dependencies of these symbols. The syntactic form of a symbol depends on the type of dependency primitives we're using. For example, goog.provide('foo.bar') provides the symbol foo.bar. Entry points can be scoped to a module by specifying mod2:foo.bar.

There are two different types of entry points, closures and modules:

• closure: A closure namespace used as an entry point. May start with goog: when provided as a flag from the command line. Closure entry points may also be formatted as: goog:moduleName:name.space which specifies that the module name and provided namespace are different
• file: Must start with the prefix file:. AES6 or CommonJS modules used as an entry point. The file path is relative to the sourceDir.

How compiler should prune files based on the provide-require dependency graph.

• NONE All input files will be included in the compilation in the order they were specified in.
• SORT_ONLY All input files will be included in the compilation in dependency order.
• PRUNE Input files that are transitive dependencies of the entry points will be included in the compilation in dependency order. All other input files will be dropped. All entry points must be explicitly defined.
• PRUNE_LEGACY (deprecated) Input files that are transitive dependencies of the entry points will be included in the compilation in dependency order. All other input files will be dropped. In addition to the explicitly defined entry points, moochers (files not explicitly defining a module) are implicit entry points.

Instructs the compiler to replace dynamic import expressions with a function call using the specified name. This allows dynamic import expressions to be externally polyfilled when the output language level does not natively support them.

Start output with 'use strict';.

Determines the set of builtin externs to load.
Options: BROWSER, CUSTOM.

List of JavaScript files containing code that declares function names or other symbols. Use closureExterns to preserve symbols that are defined outside the code you are compiling. The closureExterns parameter only has an effect if you are using a CompilationLevel of ADVANCED_OPTIMIZATIONS.
These file names are relative to baseSourceDir directory.

<closureExternDeclarations>
  <closureExternDeclaration>
    <includes>
      <include>externs/*.js</include>
    </includes>
    <excludes>
      <exclude>externs/doNotInclude.js</exclude>
    </excludes>
  </closureExternDeclaration>
</closureExternDeclarations>

Deprecated.
Deprecated, use closureExternDeclarations instead, it lets you specify includes and excludes.

Deprecated, use closureExternDeclarations instead, it lets you specify includes and excludes.

A whitelist of tag names in JSDoc. Needed to support JSDoc extensions like ngdoc.

Force injection of named runtime libraries. The format is <name> where <name> is the name of a runtime library. Possible libraries include: base, es6_runtime, runtime_type_check

If true, include the content of the source file in the source map directly (via the sourceContent property). This makes the source file bigger, but does not require the original source file to be added to the browser dev tools.

Allow injecting runtime libraries.

Whether to isolate polyfills from the global scope.

Polyfill isolation is an output mode that may optionally be used alongside polyfill injection.

Polyfill isolation was motivated by two related issues.

• sometimes, the existence of Closure polyfills on the page would cause other non-Closure-compiled code to break, because of conflicting assumptions in a polyfill implementation used by third-party code.
• sometimes, Closure-compiled code would break, because of existing polyfills on the page that violated some assumption Closure Compiler makes.

These issues were generally seen by projects compiling code for inclusion as a script on third-party websites, along with arbitrary JavaScript not under their control.

Polyfill isolation mode attempts to solve these problems by "isolating" Closure polyfills and code from other code & polyfills. It is not intended to protect against malicious actors; it is instead intended to solve cases where other polyfill implementations are either buggy or (more likely) make conflicting assumptions.

Path prefixes to be removed from ES6 & CommonJS modules.

Refers to which version of ECMAScript to assume when checking for errors in your code.
Possible values are:

• ECMASCRIPT3: Checks code assuming ECMAScript 3 compliance, and gives errors for code using features only present in later versions of ECMAScript.
• ECMASCRIPT5: Checks code assuming ECMAScript 5 compliance, allowing new features not present in ECMAScript 3, and gives errors for code using features only present in later versions of ECMAScript.
• ECMASCRIPT5_STRICT: Like ECMASCRIPT5 but assumes compliance with strict mode ('use strict';).
• ECMASCRIPT_2015: Checks code assuming ECMAScript 2015 compliance.
• ECMASCRIPT_2016: Checks code assuming ECMAScript 2016 compliance.
• ECMASCRIPT_2017: Checks code assuming ECMAScript 2017 compliance.
• ECMASCRIPT_2018: Checks code assuming ECMAScript 2018 compliance.
• ECMASCRIPT_2019: Checks code assuming ECMAScript 2019 compliance.
• ECMASCRIPT_2020: Checks code assuming ECMAScript 2020 compliance.
• ECMASCRIPT_2021: Checks code assuming ECMAScript 2021 compliance.
• ECMASCRIPT_NEXT: Checks code assuming ECMAScript latest draft standard.
• STABLE Use stable features

Refers to which version of ECMAScript your code will be returned in.
It is used to transpile between different levels of ECMAScript. Possible values are

• ECMASCRIPT3: Outputs code with ECMAScript 3 compliance.
• ECMASCRIPT5: Outputs code with ECMAScript 2015.
• ECMASCRIPT5_STRICT: Like ECMASCRIPT5 but assumes compliance with strict mode ('use strict';).
• ECMASCRIPT_2015: Outputs code with ECMAScript 2015.
• ECMASCRIPT_2016: Outputs code with ECMAScript 2016.
• ECMASCRIPT_2017: Outputs code with ECMAScript 2017.
• ECMASCRIPT_2018: Outputs code with ECMAScript 2018.
• ECMASCRIPT_2019: Outputs code with ECMAScript 2019.
• STABLE: Use stable features
• NO_TRANSPILE: Do not perform any transpilation.

Specifies how the compiler locates modules.

• BROWSER: Requires all module imports to begin with a '.' or '/' and have a file extension. Mimics the behavior of MS Edge.
• BROWSER_WITH_TRANSFORMED_PREFIXES: A limited superset of BROWSER that transforms some path prefixes. For example, one could configure this so that "@root/" is replaced with "/my/path/to/project/" within import paths.
• NODE: Uses the node module rules. Modules which do not begin with a "." or "/" character are looked up from the appropriate node_modules folder. Includes the ability to require directories and JSON files. Exact match, then ".js", then ".json" file extensions are searched.
• WEBPACK: Looks up modules from a special lookup map. Uses a lookup map provided by webpack to locate modules from a numeric id used during import.

If not an empty or blank string, interpolate output into this string at the place denoted by the marker token %output%. Use marker token %output|jsstring% to perform JavaScript string escaping on the output.

When using this options with a source map, the map is adjusted appropriately to match the code.

Normally, when there are an equal number of single and double quotes in a string, the compiler will use double quotes. Set this to true to prefer single quotes.

If true, the processed ("minified") file is pretty printed (formatted with new lines).

Processes built-ins from the Closure library, such as goog.require(), goog.provide(), and goog.exportSymbol( ).

Process CommonJS modules to a concatenable form.

Specifies the name of an object that will be used to store all non-extern globals.

Specifies a prefix that will be prepended to all variables.

If true, ES6 polyfills are written to the output file (such as for Set, Map etc.)

Source map location mapping. This is a prefix mapping from the file system path to the web server path. The source map contains a reference to the original source files; and this may be different on the web server. The location of the source file is always relative to the given sourceDir. This defines a list of replacements. For each source file, the first matching replacement is used. If the source file starts with the prefix as given by the name, it matches and is replaced with the value. For example:

<closureSourceMapLocationMappings>
  <closureSourceMapLocationMapping>
    <name>js/</name>
    <value>/web/www/js</value>
  </closureSourceMapLocationMapping>
</closureSourceMapLocationMappings>

Assume the source files are js/file1.js and js/file2.js. The above replaces them with /web/www/js/file1.js and /web/www/js/file2.js. This is then path that will be used in the source map to reference the original source file. If no location mappings are specified, the path of the source files relative to the created source map is used instead.

If you set the name to an empty string, it matches all paths.

Name of the source map, if one is created. This is interpreted as a relative path to where the processed JavaScript file is written to. By default, the extension .map is added to the minified file. Variables are specified via #{variableName}. To insert a literal #, use ##. The following variables are available:

• The variable filename is replaced with the name of the minified file
• The variable extension is replaced with the extension of the file
• The variable basename is replaced with the basename (name without the extension) of the file.

After creating the source map, the browser needs to find it. There are several options available:

• reference (the default): Create a source map named [originalFile].map, and add a reference to it in the minified file.
• file: Just create a source map named [originalFile].map, do not add a reference in the minified file. This may be useful when you want to add the Source-Map HTTP header.
• inline: Do not write a separate source map file, but instead include the source map content in the minified file (as base64). This makes it easier for the browser to find the source map. Especially useful when used with JSF/Primefaces or other frameworks that do not use standard URLs.

Assume input sources are to run in strict mode.

If false, converts some characters such as '<' and '>' to '\x3c' and '\x3d' so that they are safe to put inside a script tag in an HTML file.

Enable or disable the optimizations based on available type information. Inaccurate type annotations may result in incorrect results.

Specifies the warning level to use: QUIET, DEFAULT, or VERBOSE. You can override specific warnings via closureWarningLevels.

Treat certain warnings as the specified CheckLevel:

• ERROR: Makes all warnings of the given group to build-breaking error.
• WARNING: Makes all warnings of the given group a non-breaking warning.
• OFF: Silences all warnings of the given group.

Example:

<closureWarningLevels>
    <nonStandardJsDocs>OFF</nonStandardJsDocs>
</closureWarningLevels>

For the complete list of diagnostic groups please visit https://github.com/google/closure-compiler/wiki/Warnings.

If a supported character set is specified, it will be used to read the input file. Otherwise, it will assume that the platform's default character set is being used. The output file is encoded using the same character set.
See the IANA Charset Registry for a list of valid encoding types.

JavaScript files to exclude. Specified as fileset patterns which are relative to the JavaScript source directory.

For each bundle, this plugin performs a check whether the input or output files have changed and skips the execution in case they haven't. Set this flag to true to force the execution.

Base directory relative to which the htmlFiles to process are evaluated, see the option htmlUpdates. Relative paths are evaluated relative to the baseHtmlDir option. When not given, defaults to baseHtmlDir.

The root directory of the HTML files, see the option htmlUpdates. Used to construct a relative path from the HTML file the script file.

Relative paths are resolved against the baseHtmlRoot option. Defaults to baseHtmlRoot .

For example, assume the following configuration:

• HTML file - /home/user/project/src/main/resources/webapp/public/pages/profile/index.html
• Script file - /home/user/project/target/generated-resources/frontend/js/public/resources/main/script.min.js
• HTML root - /home/user/project/src/main/resources/webapp
• Script root - /home/user/project/target/generated-resources/frontend/js

Then, the relative path of the HTML file relative to the HTML root is public/pages/profile/index.html and the relative of the JavaScript file is public/resources/main/script.min.js.

Finally, the script file is relativized against the HTML file; and the final relative path used to update the script tag in the HTML file is ../../resources/main/script.min.js

Precedence: htmlSourcePath has the highest priority. htmlUsePhysicalRoot comes next, htmlRoot and htmlScriptRoot have the lowest priority.

The root directory of the script files, see the option htmlUpdates. Used to construct a relative path from the HTML file the script file.

Relative paths are resolved against the baseHtmlScriptRoot. Defaults to the baseHtmlScriptRoot.

For example, assume the following configuration:

• HTML file - /home/user/project/src/main/resources/webapp/public/pages/profile/index.html
• Script file - /home/user/project/target/generated-resources/frontend/js/public/resources/main/script.min.js
• HTML root - /home/user/project/src/main/resources/webapp
• Script root - /home/user/project/target/generated-resources/frontend/js

Then, the relative path of the HTML file relative to the HTML root is public/pages/profile/index.html and the relative of the JavaScript file is public/resources/main/script.min.js.

Finally, the script file is relativized against the HTML file; and the final relative path used to update the script tag in the HTML file is ../../resources/main/script.min.js

Precedence: htmlSourcePath has the highest priority. htmlUsePhysicalRoot comes next, htmlRoot and htmlScriptRoot have the lowest priority.

Allows you to set the sourcePath option globally for each htmlUpdate, see the htmlUpdates option for more details. You can still override this option for each htmlUpdate, if you wish.

Precedence: htmlSourcePath has the highest priority. htmlUsePhysicalRoot comes next, htmlRoot and htmlScriptRoot have the lowest priority.

Optional. Allows you to update script tags in an HTML file with the path of the processed file(s).

Both HTML and XHTML files are supported.

Allows you to set the usePhysicalLocation option globally for each htmlUpdate, see the htmlUpdates option for more details. You can still override this option for each htmlUpdate , if you wish.

Precedence: htmlSourcePath has the highest priority. htmlUsePhysicalRoot comes next, htmlRoot and htmlScriptRoot have the lowest priority.

JavaScript files to include. Specified as fileset patterns which are relative to the JavaScript source directory.

The line separator to be used when merging files etc. Defaults to the default system line separator. Special characters are entered escaped. So for example, to use a new line feed as the separator, set this property to \n (two characters, a backslash and the letter n).

By default, messages are logged at the log level set by maven. This option allows you to change the log level. Valid options are all, debug, info, warn, error, none. Leave empty to use the default log level. Please note that you can only decrease, not increase, the log level.

The output file name of the processed files. This is interpreted as a path relative to the targetDir.

Variables are specified via #{variableName}. To insert a literal #, use ##. The following variables are supported:

• The variable filename is replaced with the name of the minified file.
• The variable extension is replaced with the extension of the file (without the period)
• The variable basename is replaced with the basename (name without the extension) of the file.
• In case the files are not merged (option skipMerge is activated): The variable path is replaced with the path of the current file, relative to the sourceDir.

If merging files, by default the basename is set to script and the extension to , so that the resulting merged file is called script.min.js.

When set to `true`, the plugin exits immediately without doing any work at all.

Skip the merge step. Minification will be applied to each source file individually.

Skip the minify step. Useful when merging files that are already minified.

This options lets configure how this plugin checks whether it should skip an execution in case the target file exists already. Usually you do not want to spend unnecessary processing time on transpiling JavaScript files when the input files themselves have not changed. Available options are:

• NEWER - Skip execution if the the target file exists already and all input files are older. Whether a file is older is judged according to their modification date.
• EXISTS - Skip execution if the target file exists already, irrespective of when thee files were last modified.

These options only apply when force is set to false. In case you never want to skip execution, set the option force to true.

Deprecated.
For Eclipse with m2e, you can now use <?m2e ignore?> etc. on an execution tag to configure the m2e lifecycle.

Deprecated. For Eclipse with m2e, you can now use <?m2e ignore?> etc. on an execution tag to configure the m2e lifecycle.

When this plugin is executed as part of an incremental build (such as me2) and this option is set to true, skip the execution of this plugin.

For the m2e integration, this plugin is configured by default to run on incremental builds. When having a project opened in Eclipse, this recreates the minified files every time a source file is changed.

You can disable this behavior via the org.eclipse.m2e/lifecycle-mapping plugin. As this is rather verbose, this option offers a convenient way of disabling incremental builds. Please note that tecnically this plugin is still executed on every incremental build cycle, but exits immediately without doing any work.

JavaScript source directory. This is relative to the baseSourceDir.

JavaScript target directory. Takes the same value as jsSourceDir when empty. This is relative to the baseTargetDir.