[Bug][API] GET scoped package w/ version fails with 401 status

(Robert Kieffer) #1

What I Wanted to Do

curl https://registry.npmjs.org/@babel/core/latest should return JSON info about latest version of @babel/core module
Similarly, curl https://registry.npmjs.org/@webassemblyjs/wasm-parser/1.7.11 should return info for @webassemblyjs/wasm-parser@1.7.11

What Happened Instead

Server responds with 401 status

Reproduction Steps

See curl commands above

Details

This appears to be an issue with any module that has a scoped name.

This issue previously reported (and closed without response) here.

Note, too, that the information in question is available if you omit the version. E.g. curl https://registry.npmjs.org/@babel/core works… you just have to sift through the versions field to fin the information you need.

Platform Info

Problem appears to be client independent. Issue happens with curl as well as on http://npm.broofa.com (e.g. See failing XHR requests at http://localhost:9080/?q=@babel/core )

(Kat MarchĂĄn) #2

If you look at the headers, you’ll notice this one:

npm-notice: ERROR: you cannot fetch versions for scoped packages

So basically, what you’re trying to do is not supported, intentionally. You need to fetch the packument or the tarball. Individual version fetches aren’t supported. If you want to make this easier, you can use pacote to make the API call (or libnpm.manifest):

const pkg = await libnpm.manifest('@babel/core@latest')
Need help on a npm registry request
(Robert Kieffer) #3

what you’re trying to do is not supported, intentionally

But why? This seems like an arbitrary and unnecessary distinction because…

  1. Public, scoped modules are semantically no different than unscoped modules.
  2. The version-specific information is available as long as you omit the version in the URL (i.e. this isn’t a security issue)
  3. It penalizes organizations for scoping their public modules

On that last point, it’s worth pointing that this affects several well-known module collections: @babel, @angular, @ngtools, and @types, to name a few.

Is this just a byproduct of how scoped packages are handled behind the scenes or something?

(Kat MarchĂĄn) #4

That’s pretty much it, yeah.

(Simon De Lang) #5

Are there any plans to fix this in the future? We’ve just moved our packages to scoped packages and we used to API to get package.json info from the latest version of packages. Because we now have scoped packages, that doesn’t work anymore.