Add support for cli statistics reporting

[iarna]

Usage should look like:

client.sendAnonymousCLIMetrics(uri, params, cb)

• uri {String} Base URL for the registry.
• params {Object} Object containing per-request properties.
  • metricId {String} A uuid unique to this dataset.
  • metrics {Object} The metrics to share with the registry, with the following properties:
  • from {Date} When the first data in this report was collected.
  • to {Date} When the last data in this report was collected. Usually right now.
  • successfulInstalls {Number} The number of successful installs in this period.
  • failedInstalls {Number} The number of installs that ended in error in this period.
• cb {Function}

It is important that calls to this function not hold the event loop open. That is, if the program would naturally exit before this completes, we shouldn't block that exit. Ordinarily you would achieve this by unrefing any sockets/timers involved. This may not be feasible with request.

---

The end point is:

PUT /-/npm/anon-metrics/v1/:metricId

Where metricId would be a uniqueid to this set of stats. If the server sees the same uniqueid more than once then the latter version will supersede the former. This means that if one PUT fails, we can try again later with newer data and not end up double counting.

This end point expects a JSON object and ignores any keys it doesn't understand. The initial keys would be:

from: 'W3CDTF',
to: 'W3CDTF',
successfulInstalls: #,
failedInstalls: #

---

The cli issue for this: https://github.com/npm/npm/issues/12529

The registry issue for this: https://github.com/npm/registry/issues/11

[othiym23]

The current name of the method lacks a verb, which is inconsistent with the rest of the API – maybe sendAnonymousCLIStats?

[iarna]

sounds good

[iarna]

You used the term metrics in other discussion of this and I like that better than stats, so I've switched over to that instead.

[iarna]

Hey @lazywithclass, I think this is ready. An initial version that does not try to implement the "don't make the program wait" semantics would be fine. That is, if you want to do a version of this that just uses request directly, that would be quite helpful as it'd give our registry team code to work against and would let us proof-of-concept.

[iarna]

(Well I thoguht the don't make it wait would involve unrefing the socket, but it seems that doesn't apply while connecting, so we may actually end up shunting calls to this off to a separate process in the npm portion of this code.)

[lazywithclass]

Thanks for this @iarna, I will dive into the details.

A couple questions:

• it's not clear to me if the - in the URL is actually part of the endpoint, sorry if this sounds silly I've never seen this convention before
• since this is my first contribution I'm taking the same structure of lib/get.js and test/get-basic.js for this feature, is it ok?