Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] scoped registry is not respected (edit: not a bug after all) #24

Open
pgsandstrom opened this issue Feb 19, 2020 · 2 comments
Open

Comments

@pgsandstrom
Copy link

What / Why

When adding a scoped registry to my configuration, it does not appear to be respected.

When

  const conf = {
    cache: null,
    '@babel:registry': 'http://this-should-fail.example.com',
  }
  const json = (await npmRegistryFetch.json(
    '@babel/plugin-proposal-class-properties',
    conf,
  ))

This request succeeds when I would expect it to fail.

I have tried both with v6.0.2 and v7.0.0 and get the same result.

@pgsandstrom
Copy link
Author

After digging around in the source code I now understand this is intended behaviour. I just failed to parse the documentation correctly.

However, I am a bit confused why this is the intended behaviour. I am currently using libnpmconfig to parse my npm config, and it would be very nice to simply be able to pass this object to npm-registry-fetch. But to replicate the behaviour of the npm client it seems as if I would have to do something like this:

const correctConf = {...conf, spec: dependencyName}
const json = (await npmRegistryFetch.json(dependencyName, correctConf))

Wouldn't it be nicer to skip specifying spec? It feels as if my use case would be quite common.

@pgsandstrom pgsandstrom changed the title [BUG] scoped registry is not respected [BUG] scoped registry is not respected (edit: not a bug after all) Feb 22, 2020
@isaacs
Copy link
Contributor

isaacs commented May 4, 2020

Yeah, it would be nice for it to parse the path and see that it's a scoped package name, and do the thing you're expecting here.

The hazard I could see is that it might actually be saving us from some sticky name collisions as it stands right now. I'd want to make sure we're not breaking anything that folks might be depending on (even unknowingly depending on by accident).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants