Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

`npm ping` to test registry reachability #5750

Open
othiym23 opened this Issue · 23 comments

7 participants

@othiym23
Owner

As described by @yorkie and @timoxley on #5743, it would be very useful to have a simple command that ensures that the registry (either the default, or selectable via --registry) is reachable (and, optionally, that your credentials for that registry are valid).

This would be very useful to have as a troubleshooting tool available to npm report (#5214).

@yorkie

haha, that's great :)

@tjwebb

Yea, someone host npm-report.herokuapp.com. badabing, independent npm registry status

@othiym23
Owner

npm, Inc. is already using pingdom and Nagios and a bunch of other checks to verify registry availability, but that doesn't help you at all if you're running the CLI from behind a dodgy proxy or over a flaky connection. npm ping, as described, is a troubleshooting tool for end users, rather than an availability monitoring tool.

@michaelnisi

Which existing HTTP endpoint of the registry (or client function) do you suggest to use for pinging?

@michaelnisi

Just getting familiar with npm's source, I naively assumed I could just write a quick npm-ping module:

var RegClient = require('npm-registry-client')
  , npmconf = require('npmconf')
  ;

module.exports.ping = ping

function conf (cb) {
  var loaded = npmconf.loaded
  loaded ? cb(null, loaded) : npmconf.load(cb)
}

function ping (cb) {
  conf(function (er, conf) {
    var client = new RegClient(conf)
      , reg = conf.get('registry')
      ;
    client.whoami(reg, function (er, who) {
      cb(er, who)
    })
  })
}

/* Example */
ping(function (er, res) {
  console.log(res) 
  // results in a 404 (er = null, res = undefined)
})

Well, not really—hints welcome.

@othiym23
Owner

whoami is currently an endpoint that isn't on the main npm registry, but in general, if you can fetch the info on a package using npm-registry-client (and it parses as valid JSON), npm's probably going to work. If you can fetch that info with ?write=true, your credentials are set correctly. Look at lib/star.js in npm-registry-client for an example.

Eventually, I'd like to have a safe ping endpoint in the registry, as well as a corresponding command in npm-registry-client, but something a little looser like what you've started working on is a good place to start. Thank you, and let me know if you need further help!

@tjwebb

I'm not sure what a designated ping endpoint would tell us besides whether the designated ping endpoint is working or not. Unless it then polls the internal infrastructure for status?

@othiym23
Owner

It would tell you that your installation of npm can reach the registry, and that your credentials are valid. This may not seem like very much, but it's a hugely valuable tool for front-line support, especially when helping newer users who are unfamiliar with npm and node and looking to get their setup dialed in.

@tjwebb

Yea, +1 front line support. What comes to my mind is the npmjs.org status page, on which I've never seen anything but glowing success, even when I'm having connectivity issues with the registry. As long as npm ping is clear as to what it should convince me of, it sounds like a helpful debug/sanity tool.

@michaelnisi

Thanks, I'll see what I can do.

@mreinstein

Could we instead improve the error messages when there are npm failures of this kind? Having to build a debug subcommand just to tell us why things are going wrong seems like a heavy workaround for better error messages in the cli.

@othiym23
Owner

That is also a thing we want to do! But having a separate troubleshooting command will be very useful for support and remote help.

@mreinstein

with descriptive error messages wouldn't it be pretty trivial to see it a glance what the problem is? I hope this isn't coming off as snarky, it just seems odd to build a fancy diagnostics tool into npm to work around ambiguous/cryptic errors.

@tjwebb

There are a lot of ambiguous/cryptic errors. Since npm correctly prefers to fail rather than try to roll with the punches and give you something that may or may not work, it is the messenger for quite a broad scope of impressively-confounding errors. And it's also the cause of some of them, on occasion.

@mreinstein

it is the messenger for quite a broad scope of impressively-confounding errors.

understood. But by that same reasoning, if the diagnostic tool is able to figure out what those errors are, couldnt that logic instead be in the error display? Or are you saying that the low level output of the diagnostic command would need to be grok'd by a human to make sense of things anyway?

@tjwebb
@rlidwka

It should probably show all information related to the network.

Using proxy? Should print that out (and possibly reachability of the registry without it).

Using HTTPS? Try plain HTTP without credentials, and see if there're any nasty intercepting proxies.

etc.

@othiym23
Owner

You're using expert minds to think about a beginner's problem. There are many tickets that get filed by newcomers to npm; either they're new Node developers, or full-stack developers using npm as part of their support tooling. They may never have seen a V8 stack trace before, and the evidence is that most of them don't know how to read them. Having a simple tool that provides unambiguous feedback that they can reach the registry makes it much easier to support them.

@yorkie

so what's the problem of @michaelnisi's patch?

@yorkie

Yeah if they work :)

@othiym23
Owner

I'll need to take a look at it again, and that's still working its way to the top of the stack. Thanks to everyone for their patience!

@reconbot

This is exactly what I'd use for front line support too! I'd like to also suggest a npm status for cli access to the status.npmjs.org. Answering is this broken or is it me (or my network) easily would be a dream.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.