Bower Repositories

Bower is a package manager for front-end web development. JavaScript developers using Bower gain convenient access to a large amount of packages from the remote Bower registry. This reduces the complexity of their development efforts and improves the resulting applications.

Nexus Repository Manager Pro and Nexus Repository Manager OSS support the Bower registry format for hosted and proxy repositories. This allows the repository manager to take advantage of the packages in the official Bower registry and other public registries without incurring repeated downloads of packages.

The official Bower registry is available for searches at http://bower.io/search and for package retrieval via the URL https://registry.bower.io.

You can publish your own packages to a private Bower registry as a hosted repository on the repository manager and then expose the remote and private repositories to Bower as a repository group, which is a repository that merges and exposes the contents of multiple repositories in one convenient URL. This allows you to reduce time and bandwidth usage for accessing Bower packages a registry as well as share your packages within your organization in a hosted repository.

You can set up a Bower proxy repository to access a remote repository location, for example the official Bower registry at https://registry.bower.io that is configured as the default on Bower.

To proxy a Bower registry, you simply create a new bower (proxy) as documented in Repository Management in detail.

Minimal configuration steps are:

The Bower specific configuration section include the setting to Enable rewrite of package URLs. This causes Bower to retrieve components and their dependencies through the repository manager even if original metadata has hard-coded URLs to remote repositories. This setting Force Bower to retrieve packages via the proxy repository is enabled by default.

If deactivated, no rewrite of the URL occurs. As a result, the original component URL is exposed. Turning off rewrite capabilities proxies the information directly from the remote registry without redirecting to the repository manager to retrieve components.

Creating a Bower hosted repository allows you to register packages in the repository manager. The hosted repository acts as an authoritative location for these components. This effectively creates an asset that becomes a pointer to an external URL (such as a Git repository).

To add a hosted Bower repository, create a new repository with the recipe bower (hosted) as documented in Repository Management.

Minimal configuration steps are:

A repository group is the recommended way to expose all your Bower repositories from the repository manager to your users, with minimal additional client side configuration. A repository group allows you to expose the aggregated content of multiple proxy and hosted repositories as well as other repository groups with one URL in tool configuration. This is possible for Bower repositories by creating a new repository with the bower (group) recipe as documented in Repository Management.

Minimal configuration steps are:

Bower is typically installed with npm. Since the repository manager supports NPM repositories for proxying, we recommend to configure the relevant NPM repositories and npm as documented in npm Registry prior to installing Bower. Once this is completed you can install Bower with the usual command.

npm install -g bower 

Bower version 1.5 or higher is required and can be verified with

$ bower -v
1.7.7 

In addition Bower requires a custom URL resolver to allow integration with Nexus Repository Manager Pro and Nexus Repository Manager OSS. The resolver is an API introduced in Bower version 1.5. Bower fetches component and version information through the repository manager, then automatically searches and saves the component in the repository. You can install the resolver with:

npm install -g bower-nexus3-resolver

Alternatively you can install the resolver on a per-project basis instead by adding it as a dependency in your package.json:

"devDependencies" : {
   "bower-nexus3-resolver" : "*"
}

Once you have set up your repositories for Bower packages, and installed Bower and the custom resolver, you can create a .bowerrc JSON file to access registry URLs. The registry value is configured to access the Bower repository group that exposes the proxy and hosted repositories together. The resolvers configuration is necessary, so that Bower uses the required custom resolver.

Global .bowerrc file in your home directory for package download via the group bower-all

{
  "registry" : {
    "search" : [ "http://localhost:8081/repository/bower-all" ]
   },
 "resolvers" : [ "bower-nexus3-resolver" ]
}

With this configuration in place, any further Bower command invocations trigger package downloads via the repository manager.

Running an install command logs the download via the repository manager:

$ bower install jquery
bower jquery#*
  not-cached nexus+http://localhost:8081/repository/bower-all/jquery#*
bower jquery#*
  resolve nexus+http://localhost:8081/repository/bower-all/jquery#*
bower jquery#*
  resolved nexus+http://localhost:8081/repository/bower-all/jquery#2.2.0
bower jquery#^2.2.0  install jquery#2.2.0

jquery#2.2.0 bower_components/jquery

If anonymous access to the repository manager is disabled, you have to specify the credentials for the accessing the repository manager as part of the URL like http://username:password@host:port/repository/bower-all and add a nexus section to your .bowerrc file.

{
  "nexus" : {
    "username" : "myusername",
    "password" : "mypassword"
  }
} 

Downloaded packages are cached, do not have to be retrieved from the remote repositories again and can be inspected in the user interface.

You can browse Bower repositories in the user interface inspecting the components and assets and their details, as described in Searching for Components.

Searching for Bower packages can be performed in the user interface, too. It finds all packages that are currently stored in the repository manager, either because they have been pushed to a hosted repository or they have been proxied from an upstream repository and cached in the repository manager.

If you are authoring your own packages and want to distribute them to other users in your organization, you have to register them to a hosted repository on the repository manager. This establishes a metadata file in the repository that links to the source code repository. Typically this is a git repository. The consumers can then download it via the repository group as documented in Configuring Bower Package Download.

You can specify the URL for the target hosted repository in the register value in your .bowerrc file. If you are registering all packages you create in the same hosted repository you can configure in the your global configuration file e.g. located in your users home directory:

{
    "registry" : {
        "search" : [
            "http://localhost:8081/repository/bower-all"
        ],
        "register" : "http://localhost:8081/repository/bower-internal"
   },
   "resolvers" : [ "bower-nexus3-resolver" ]
}

Alternatively, if you desire to use a per-project .bowerrc file that you potentially version in your source code management system with the rest of the package code, you can use a simplified file:

"registry": {
   "register": "http://localhost:8081/repository/bower-internal"
   }

Authentication is managed in the same manner as for proxying with anonymous access disabled as documented in Configuring Bower Package Download, e.g. "register": "http://admin:admin123@localhost:8081/repository/bower-hosted". With this configuration you can run a command such as:

bower register example-package git://gitserver/project.git

All semantic version tags on the git repository are now exposed as version for this package and consumers can install the package via the repository group like any other package.

bower install example-package