Installer bower avec Homebrew

Liens du projet

• Page d'accueil

Commandes et alias

• bower

Historique du projet

The official About page says Bower was created at Twitter by @fat and @maccman and released as part of Twitter's open source effort in 2012. The public GitHub repository was created in September 2012 and describes the project as a package manager for the web.

Bower's design targeted front-end assets rather than Node modules. The README and homepage emphasize a generic, unopinionated solution, no shared system-wide dependencies, a flat dependency tree, Git-based package resolution, and package-agnostic components containing JavaScript, CSS, fonts, images, or other web assets.

Historique d'adoption

Bower became widely used by front-end projects that wanted predictable browser dependency installation before the npm ecosystem fully embraced front-end packages. Its registry, `bower.json`, `.bowerrc`, and `bower_components/` directory became common project artifacts.

By 2017, the official Bower site and blog were already recommending Yarn and build tools for new front-end projects. The migration blog explains that Yarn 1.x could install many Bower packages but not resolve Bower dependencies directly, leading to compatibility helpers such as `bower-away` for legacy projects.

Modes d'utilisation

Users installed Bower globally with npm, then ran commands such as `bower install`, `bower search`, `bower info`, `bower update`, and `bower register`. Dependencies were recorded in `bower.json`, installed into `bower_components/`, and controlled with `.bowerrc` settings.

Bower intentionally did not concatenate, minify, or bundle code; it installed the requested versions and left integration to tools such as Grunt, gulp, RequireJS, webpack, or later build systems.

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

Bower matters because it captures a transitional moment in JavaScript packaging: browser packages still often lived as Git repositories with dist files, npm was not yet the universal front-end registry, and flat dependency graphs looked attractive for avoiding duplicate browser payloads.

Its decline is equally instructive. The official recommendation to use Yarn and bundlers for new projects marks the shift from asset-package managers toward npm-centered dependency graphs, lockfiles, checksums, and integrated build pipelines.

Chronologie

• 2012: Created at Twitter and released as part of Twitter's open source effort.
• 2012: Public GitHub repository created.
• 2014: GitHub Releases include the 1.x release line.
• 2017: Official Bower blog published migration guidance away from Bower.
• 2020s: Maintained mainly for legacy projects while the site recommends Yarn and modern build tools for new work.

Related projects

• npm is the package manager whose registry and package format eventually absorbed much front-end package distribution.
• Yarn is the replacement recommended by the official Bower site for many new or migrated front-end projects.
• webpack, Vite, Parcel, Grunt, gulp, and RequireJS are related build or module tools that either complemented Bower or replaced the workflow around it.

Sources

• https://api.github.com/repos/bower/bower
• https://bower.io/
• https://bower.io/blog/2017/how-to-migrate-away-from-bower/
• https://bower.io/docs/about/
• https://bower.io/docs/api/
• https://bower.io/docs/config/
• https://github.com/bower/bower