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
|