Installer closure-compiler avec Homebrew, apt

Liens du projet

• Page d'accueil
• Dépôt
• Docs amont
• Page du gestionnaire de paquets

Commandes et alias

• closure-compiler

Historique du projet

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.

Historique d'adoption

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.

Modes d'utilisation

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.

Pourquoi les passionnés de paquets s'y intéressent

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.

Chronologie

• 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