Stephen Belanger

I might look at it a bit tomorrow, if I can get through the Promises issue quickly.

Both this issue and #29 are producing the same error and both have stack traces pointing to loopback and supertest. I suspect this has something to do with how loopback...

A few things: - npm already has a cache, so changing where modules are located would have no impact on traffic to the registry. - Changing the code semantics of...

Yeah, our own data shows users basically _never_ install odd releases, so they're kind of superfluous. We're just adding extra complication to the release cycle by doing them.

As far as I can tell odd versions are only ever used in CI because we've trained people to think people might actually be using those versions in production. But...

Agreed, though I don't feel like this proposal worsens the experience of those non production server use cases in any way that I can see. I think generally less complex...

It would still be of value to have diagnostics_channel in there, yes. Though it probably needs reworking at this point to get it up-to-date. At the time we opted for...

I've forwarded it to the relevant person internally so _hopefully_ we'll come up with some solution soon...

The global `fetch` API is supported in recent releases and should be fully working since 4.9.0/3.30.0/2.43.0. If you upgrade you can remove the `--no-experimental-fetch` flag and get proper visibility. Apologies...

Yeah, hadn't really considered how node-fetch as a polyfill interacts when it switches to built-in fetch once it was available. Recent versions should have full support for global fetch though...