| 1 | # npm-registry
|
| 2 |
|
| 3 | To keep myself sane while working with The npm Registry I decided to write my
|
| 4 | own library to deal with all the incomplete, inconsistent and horrible data
|
| 5 | structures that are available in The npm Registry. NoSQL is nice and all, but
|
| 6 | that doesn't mean you should leave your data unmaintained. This library is never
|
| 7 | meant as a full replacement of the `npm-registry-client` which the `npm` bin
|
| 8 | file is using. Unless those API's and methods are so poorly implemented or
|
| 9 | designed that I get a mental breakdown, then yes, this will become a full and
|
| 10 | usable replacement of the above said module.
|
| 11 |
|
| 12 | This module is written with high availability in mind. The main reason behind
|
| 13 | this is that npm Inc. has added a lot of moving parts on top of the registry
|
| 14 | which frequently breaks. In order to combat this I've implemented automatic
|
| 15 | downgrading to multiple registries. If all other supplied registries fail to
|
| 16 | work an automatic exponential randomized back off algorithm kicks in place and
|
| 17 | retries the query once more. This functionality is all provided by the awesome
|
| 18 | [mana] package which provides core functionality for writing sane api-clients.
|
| 19 |
|
| 20 | ## Installation
|
| 21 |
|
| 22 | ```
|
| 23 | npm install --save npm-registry
|
| 24 | ```
|
| 25 |
|
| 26 | And that is all you need to type in your terminal in order to prevent becoming
|
| 27 | terminal. The `--save` tells `npm` to automatically add the package and latest
|
| 28 | version to your `package.json`.
|
| 29 |
|
| 30 | ### Packages
|
| 31 |
|
| 32 | The `.packages` endpoints allows you to retrieve detailed information about npm
|
| 33 | packages. The following methods are implemented:
|
| 34 |
|
| 35 | - `npm.packages.get`: Basic module information.
|
| 36 | - `npm.packages.depended`: List modules that depend on the given module.
|
| 37 | - `npm.packages.starred`: List users who starred the module.
|
| 38 | - `npm.packages.keyword`: List packages who use this keyword.
|
| 39 | - `npm.packages.releases`: All releases for a module.
|
| 40 | - `npm.packages.release`: The latest release.
|
| 41 | - `npm.packages.details`: Highly detailed information about the package.
|
| 42 |
|
| 43 | ### Users
|
| 44 |
|
| 45 | The `.users` endpoint allows you to retrieve detailed information about a given
|
| 46 | npm account. The following methods are implemented:
|
| 47 |
|
| 48 |
|
| 49 | - `npm.users.list`: All packages released by the user.
|
| 50 | - `npm.users.starred`: Packages that the user has starred.
|
| 51 | - `npm.users.get`: Get the profile information.
|
| 52 |
|
| 53 | ## Normalization
|
| 54 |
|
| 55 | As the internal data structure is do damn awkward in npm we need to normalize the
|
| 56 | data structures before we can even try to use it. While this normalization is
|
| 57 | part automatically done for you internally there might be use cases where you
|
| 58 | want to manually normalize a given dataset.
|
| 59 |
|
| 60 | The normalize module can be required directly using:
|
| 61 |
|
| 62 | ```js
|
| 63 | var normalize = require('npmjs/normalize');
|
| 64 | ```
|
| 65 |
|
| 66 | The `normalize` variable now contains two different functions, `users` and
|
| 67 | `packages`. As you might have guessed, these functions normalize different data
|
| 68 | structures. The function accepts a simple single argument which is the data
|
| 69 | object that you receive from the npm registry endpoints.
|
| 70 |
|
| 71 | ```js
|
| 72 | data = normalize.packages(data);
|
| 73 | ```
|
| 74 |
|
| 75 | ## License
|
| 76 |
|
| 77 | MIT
|
| 78 |
|
| 79 | [mana]: http://github.com/3rd-Eden/mana
|