Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

`npm ping` to test registry reachability #5750

Closed
othiym23 opened this Issue Jul 21, 2014 · 24 comments

Comments

Projects
None yet
8 participants
Contributor

othiym23 commented Jul 21, 2014

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).

Contributor

yorkie commented Jul 22, 2014

haha, that's great :)

tjwebb commented Jul 23, 2014

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

Contributor

othiym23 commented Jul 23, 2014

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.

Contributor

michaelnisi commented Jul 23, 2014

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

Contributor

michaelnisi commented Jul 23, 2014

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.

Contributor

othiym23 commented Jul 23, 2014

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 commented Jul 23, 2014

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?

Contributor

othiym23 commented Jul 23, 2014

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 commented Jul 23, 2014

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.

Contributor

michaelnisi commented Jul 23, 2014

Thanks, I'll see what I can do.

This was referenced Jul 24, 2014

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.

Contributor

othiym23 commented Aug 8, 2014

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

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 commented Aug 8, 2014

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.

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 commented Aug 8, 2014

Yea, the obvious inherent problem of unreliable software trying to
interpret and communicate to a human the nature of its own unreliableness.

On Fri, Aug 8, 2014 at 2:50 AM, Mike Reinstein notifications@github.com
wrote:

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?


Reply to this email directly or view it on GitHub
#5750 (comment).

Contributor

rlidwka commented Aug 8, 2014

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.

Contributor

othiym23 commented Aug 8, 2014

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.

Contributor

yorkie commented Aug 8, 2014

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

Contributor

michaelnisi commented Aug 8, 2014

Referring to these?
npm/npm-registry-client#55
#5788

Contributor

yorkie commented Aug 8, 2014

Yeah if they work :)

Contributor

othiym23 commented Aug 8, 2014

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!

Contributor

reconbot commented Sep 11, 2014

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.

@zkat zkat added a commit that referenced this issue Jun 30, 2015

@michaelnisi @zkat michaelnisi + zkat Add ping command
Fixes #5750

PR-URL: #5788
f1f7a85

@iarna iarna added a commit that referenced this issue Jul 1, 2015

@michaelnisi @iarna michaelnisi + iarna npm: Add ping command
Fixes #5750

PR-URL: #5788
69e4c22

@iarna iarna closed this in 311db70 Jul 1, 2015

Contributor

legodude17 commented Jun 16, 2016

I would want something like npm ping $package then it would attempt to fetch $package from the registry. And then npm fetch $package to just fetch and unzip the tarball of package.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment