To keep myself sane while working with The npm Registry I decided to write my
own library to deal with all the incomplete, inconsistent and horrible data
structures that are available in The npm Registry. NoSQL is nice and all, but
that doesn't mean you should leave your data unmaintained. This library is never
meant as a full replacement of the
npm-registry-client which the
file is using. Unless those API's and methods are so poorly implemented or
designed that I get a mental breakdown, then yes, this will become a full and
usable replacement of the above said module.
This module is written with high availability in mind. The main reason behind this is that npm Inc. has added a lot of moving parts on top of the registry which frequently breaks. In order to combat this I've implemented automatic downgrading to multiple registries. If all other supplied registries fail to work an automatic exponential randomized back off algorithm kicks in place and retries the query once more. This functionality is all provided by the awesome mana package which provides core functionality for writing sane api-clients.
npm install --save npm-registry
And that is all you need to type in your terminal in order to prevent becoming
npm to automatically add the package and latest
version to your
Now that you've installed the
npm-registry module you can require and
initialize it using:
'use strict';var Registry = ;var npm = options ;
As seen in the example above, the
Registry constructor allows an
options to customize the npm registry client. The following options are supported:
registryThe URL of the npm registry. Defaults to Nodejitsu's mirror.
statsURL of the download stats service. Defaults to npm's API server.
mirrorsArray of mirrors to use when a registry is down.
maxdelayMaximum delay for exponential back off.
mindelayMinimum delay for exponential back off.
githulkReference to a pre-configured GitHulk instance.
retriesThe amount of retries we should do before giving up.
factorExponential backoff factor.
authorizationOptional authorization header for authorized requests.
user,passwordOptional user/password for authorized requests.
The fully configured npm registry client can then be used to access the various of API endpoints using:
//// npm.<endpoint>.<method>(<arg>, <callback>);//npmpackages;
The following endpoints are available:
.packages endpoints allows you to retrieve detailed information about npm
packages. The following methods are implemented:
Get information from the npm package. If the name contains an
@ char we assume
that the user wants to get a specific version instead.
Example: email@example.com would retrieve primus version 0.1.1
Retrieve additional details for the package information. This a lot slower than
.get but much more detailed and accurate as it uses custom parsers
for accurate licensing information. Which could require a fair amount of npm and
Get all packages that are depended upon a given package name.
Find out which users have starred the given package.
Find all packages that matches the giving keywords.
Retrieve all release specific information for the given package name. Please
note that this uses the
npm.packages.details call under the hood to provide
more detailed information but it will therefor also take longer.
Get a specific release of a package. Please note that this uses the
npm.packages.details call under the hood to provide more detailed information
but it will therefor also take longer.
Get a release that is satisfying a given semver range. Please note that this
npm.packages.details call under the hood to provide more detailed
information but it will therefor also take longer.
.users endpoint allows you to retrieve detailed information about a given
npm account. The following methods are implemented:
Add a user as maintainer of a package.
Create a new npm account.
Update the users.
List all packages that the user maintains.
Get all packages that the user has starred.
Get profile information for a given user.
Sync ownership of npm modules with another account. This is useful if you have one base owner of modules like a corporate account and you want to on-board a new user.
.downloads endpoint allows you to retrieve download stats for a given
package. The following methods are implemented:
Get the total amount of downloads for a given period. If no package name has been supplied the total of all packages will be returned. The following date ranges are accepted by the stats server.
- All packages, last day:
- last day:
- specific date:
- last week: `last-week
- range of date (30 days max):
- last month:
- specific month:
Same as above, but it doesn't get the total/summary of the downloads but an array with the downloads per day. The same date ranges are allowed and if no package name is supplied, all packages is assumed.
As the internal data structure is do damn awkward and unmaintained in npm we need to normalize the data structures before we can even try to use it. While this normalization is part automatically done for you internally there might be use cases where you want to manually normalize a given dataset. The normalize module can be required directly using:
var normalize = ;
normalize variable now contains two different functions,
packages. As you might have guessed, these functions normalize different data
structures. The function accepts a simple single argument which is the data
object that you receive from the npm registry endpoints.
data = normalize;