README
slightly-less-simple-bower-registry
A simple registry server compatible with bower 1.x. Designed for those who want to host their own private registry, but also need a simple web interface to browse through the bower packages. Scroll down a bit for more information on the difference between @wibblymats excellent simple-bower-registry and this fork/spinoff project, slightly-less-simple-bower-registry
Usage
Install with npm install -g slightly-less-simple-bower-registry
.
Then you can run the server as start-bower-registry
.
The server runs on port 3333 by default. You can specify a different port number by passing in a --port=XXXX
parameter
start-bower-registry --port=1234
By default the registry data is stored in a single file called package-data.json
.
You can specify a different file by passing in the --storage
paramenter, e.g.
start-bower-registry --storage="./registryData.json"
To use your server with bower, update (or create) a .bowerrc file
either in your home directory or in the directory for the package
you are working on that needs the private registry.
Create a key of registry
and set it to the URL of the registry server, e.g.
{
"registry": "http://localhost:3333"
}
If you would like your setup to try searching your private registry, then the normal public one, configure your .bowerrc file as such:
{
"registry" : {
"search" : [ "http://localhost:3333","http://bower.herokuapp.com/" ],
"register" : "http://localhost:3333"
}
}
Differences from the live bower registry
- If you make a mistake when registering a package, you can just submit it again and it will overwrite the existing one.
- You can use any valid endpoint, not just
git://
URLs. - There is no database to manage. The data is kept in memory and persisted to a plain JSON file.
Differences from simple-bower-registry
The original simple-bower-registry by @wibblymat is beautifully simple and lightweight but when we started using it, there were some frequently asked for features. Primarily, the ability to get a list and search through all the packages on a registry, as well as learning all the available versions and dependencies of a package.
So this fork is nowhere near as simple as the original,
but it now has the /view
context path created, which
displays the list of packages neatly, as well as providing
more information to the users that want to dig deeper.
This code is terrible!
Probably! Checkout my github page, it's pretty empty at the moment. I'm still quite new at this, so please, let me know why the code is terrible and how I can unterrible-ise it.