Install closure-compiler with Homebrew, apt

Project links

• Homepage
• Repository
• Upstream docs
• Package manager page

Commands and aliases

• closure-compiler

Project history

Google introduced Closure Tools in 2009, including Closure Compiler, Closure Library, Closure Templates, and Closure Inspector. The compiler's role was to parse JavaScript, perform type and syntax checks, remove dead code, and rewrite code for smaller downloads and faster execution.

The current GitHub repository is maintained by Google and documents the compiler as a whole-program optimizer whose strongest mode, ADVANCED, expects code written with Closure Compiler's assumptions in mind. The README also records the project's long relationship with Closure Library style modules and its more limited fit with modern arbitrary JavaScript bundles.

Adoption history

Google's launch post tied Closure Tools to JavaScript-heavy products such as Gmail, Google Docs, and Google Maps, which made the compiler historically important as a public version of infrastructure used in large browser applications.

Distribution broadened beyond direct Java JAR usage: the upstream README points to Maven artifacts and notes npm/Yarn installation through the separate google-closure-compiler npm packaging maintained outside Google. The Homebrew, Debian, and Ubuntu package-manager facts in the input show that the CLI also became a conventional system package.

How it is used

Typical CLI use compiles one or more JavaScript inputs to an output file, with SIMPLE or ADVANCED optimization levels. The compiler can also check types and conformance, transpile newer JavaScript for older browsers, emit source maps, and split output into loadable chunks.

The project is best treated as a specialized optimizer for codebases prepared for its rules, especially when property renaming, externs, and Closure-style module conventions matter.

Why package nerds care

Closure Compiler matters to package nerds because it crosses packaging cultures: Java artifacts, npm command wrappers, Linux distro packages, and Homebrew all expose the same optimizer with different expectations about runtime, update cadence, and command names.

It is also a useful example of a package whose canonical upstream warns that one popular distribution path, npm, is built by an outside maintainer from a separate repository, so package provenance matters.

Timeline

• 2009: Google introduced Closure Tools and open sourced Closure Compiler.
• 2014: The current google/closure-compiler GitHub repository metadata was created.
• 2024: The README documented deprecation or reduced support for some non-ADVANCED and non-Closure-style module paths.

Related projects

• Closure Library, Closure Templates, and Closure Inspector were announced with Closure Compiler as related Closure Tools.
• closure-compiler-npm is the separate npm packaging repository named by the upstream README.
• Modern JavaScript bundlers and minifiers overlap with Closure Compiler in SIMPLE-style minification, while Closure Compiler remains distinctive as a whole-program optimizer.

Sources

• https://developers.googleblog.com/introducing-closure-tools/
• https://developers.google.com/closure/compiler/docs/overview
• https://github.com/google/closure-compiler#readme