Scoped packages return 404

[diervo]

Scoped packages return a 404, for example the command: npm info @types/node --registry=http://myregistry.com fails.

That being said it worked a couple of times so It might be related somehow with the issue #96 and #97, since it did work intermittently?

Note that in my server I do have applied the PR #98

[diervo]

Ok I found the root cause: There is a a bunch of race conditions in http-call library due to incorrect use of async/await.

The problem is described here: https://jakearchibald.com/2017/await-vs-return-vs-return-await/

Because of this the property req.body might be a string or JSON depending if the promise has been resolved.

[BobNobrain]

I still have this issue in 2.8.2 with env variable NPM_REGISTER_AUTH_READ=true. All scoped packages return 404, but everything else works as intended. In logs it says just something like this:

[API] measure#request=6ms method=GET user-agent="npm/6.4.1 node/v8.11.1 linux x64" status=404 path=/@nuxtjs/axios request_id=0.9942495738552943

[giantryansaul]

I could use some help here. The service works well for me when I've deleted the lock file, but when I use a set yarn.lock file I run into frequent 404 errors. AFAIK all of the dependencies are otherwise available.

[dgautsch]

@BobNobrain @giantryansaul I'll review sometime this weekend and next week. Haven't had as much time for this project lately. But should have some free time over the holiday.

[dgautsch]

@giantryansaul when you say, set yarn.lock. do you mean the one committed with the project that comes with v2.8.3?

[giantryansaul]

@dgautsch No I mean the yarn lock file we use for our team's project. I've reset the "resolved" links from the public yarn registry so that they all get re-written to this new registry. All of these packages will download correctly from the public registry, but a handful of them (mostly @type libraries) will get 404 errors.

[silverlyra]

I just ran into this in switching from verdaccio to npm-register.

Most of the scoped packages in our yarn.lock files had URL-escaped /s within their tarball URLs, like https://npm.abc.xyz/@vx%2ftext/-/text-0.0.165.tgz. But some of them did not, and npm-register 404’d them: https://npm.abc.xyz/@vx/text/-/text-0.0.165.tgz won’t work. Looking through routes.js, it looks like those might work if the tarball name had a /hash suffix.

We used sed to url-escape all scoped package names in our yarn.lock files, and then our yarn installs started to complete successfully.