github/bower
1
1
Fork 0
mirror of https://github.com/bower/bower.git synced 2026-04-24 03:00:19 -04:00
Code Issues Packages Projects Releases Wiki Activity

Updates to README

Browse Source
This commit is contained in:
Michael Uzquiano
2012-10-02 14:28:13 -04:00
parent 0e0a1c6432
commit d8ffbe2c33
1 changed files with 34 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

46
README.md
View File

@@ -30,12 +30,6 @@ To install a package:
As you can see, packages can be installed by name, Git endpoint, URL or local path.
[View all packages available through Bower's registry](http://sindresorhus.com/bower-components/).
During install you can have Bower add an entry to your component.json as well:
bower install --save jquery
To update a package, reference it by name:
bower update jquery-ui
@@ -50,6 +44,37 @@ To search for packages:
To list all the available packages, just call `bower search` without specifying a name.
### Bower Configuration
Bower can be configured by creating a ~/.bowerrc file with one or all of the following configuration parameters.
```json
{
"directory" : "components",
"json" : "component.json",
"endpoint" : "https://bower.herokuapp.com",
"searchpath" : []
}
```
To run your own Bower Endpoint for custom components/packages that are behind a firewall you can use a simple implementation of bower server at https://github.com/twitter/bower-server.
The __searchpath__ array provides additional URLs of read-only Bower registries that should be consulted to look up components. This is most typically used if your business wishes to
house some components internally while still taking advantage of public Bower registries. For example, you might configure the following:
```json
{
"directory" : "components",
"json" : "component.json",
"endpoint" : "http://bower.mycompany.com",
"searchpath" : ["https://bower.herokuapp.com"]
}
```
Bower will first look to __http://bower.mycompany.com__ while trying to find your components. If not found, the main registry at __https://bower.herokuapp.com__ will be consulted to
see if a copy of the resource can be retrieved.
### Defining a package
You can create a `component.json` file in your project's root, specifying all of its dependencies. This is similar to Node's `package.json`, or Ruby's `Gemfile`, and is useful for locking down a project's dependencies.
@@ -80,8 +105,6 @@ For now, `name`, `version`, `main`, and `dependencies` are the only properties t
}
```
There should only be at most one file per file type in the `main` list. So only one `.js` or `.css`.
### Installing dependencies
Dependencies are installed locally via the `bower install` command. First they’re resolved to find conflicts. Then they’re downloaded and unpacked in a local subdirectory called `./components`, for example:
@@ -147,17 +170,16 @@ Bower then makes available a simple programmatic API which exposes the package d
### FAQ
**What distinguishes Bower from Jam, Volo, Component, or Ender? What does it do better?**
**What distinguishes Bower from Jam, Volo or Ender? What does it do better?**
Bower is a lower level component than Jam, Volo, Component, or Ender. These managers could consume Bower as a dependency.
Bower is a lower level component than Jam, Volo, or Ender. These managers could consume Bower as a dependency.
Bower's aim is simply to install Git paths, resolve dependencies from a `component.json`, check versions, and then provide an API which reports on these things. Nothing more. This is a major diversion from past attempts at browser package management.
Bower is working under the assumption that there is a single, common problem in frontend application development: dependency resolution. Past attempts (Jam, Volo, Ender, Component) try to tackle this problem in such a way that they actually end up alienating and further segregating the JavaScript community around transports (Sprockets, CommonJS, RequireJS, regular script tags).
Bower is working under the assumption that there is a single, common problem in frontend application development: dependency resolution. Past attempts (Jam, Volo, Ender) try to tackle this problem in such a way that they actually end up alienating and further segregating the JavaScript community around transports (Sprockets, CommonJS, RequireJS, regular script tags).
Bower offers a generic, unopinionated solution to the problem of package management, while exposing an API that can be consumed by a more opinionated build stack.
**Volo is an arguably more established project and works with the GitHub search API. Will it take long for Bower to contain a decent number of packages?**
Bower (being a Git powered package manager) should, in theory, be capable of consuming every package that Volo does, with the additional benefit of supporting internal networks and other Git repositories not hosted on GitHub.