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

[RRFC] The .npmrc file should be valid for any dependency, whether direct or indirect #569

Open
fltenwall opened this issue Apr 18, 2022 · 1 comment

Comments

@fltenwall
Copy link

Motivation

The background of this problem is that I have A project whose direct dependency on A is A ', and another direct dependency on B that depends on C is C '. After I set the corresponding cache to A and C in the.npmrc file, the indirect dependency on C will not take effect and its address will be the global address

Example

registry=https://registry.npm.taobao.org/
A:registry=A'
C:registry=C'

The directly dependent address of A is the correct A ', but the address of indirect C is the global registry

How

Current Behaviour

The setting of indirect dependencies is invalid in the '.npmrc' file

Desired Behaviour

Both direct and indirect dependencies should be downloaded correctly according to the configuration

References

  • Related/Reference to #4762
@darcyclarke darcyclarke added the Agenda will be discussed at the Open RFC call label Apr 20, 2022
@darcyclarke darcyclarke changed the title [RRFC] The.npmrc file should be valid for any dependency, whether direct or indirect [RRFC] The .npmrc file should be valid for any dependency, whether direct or indirect Apr 27, 2022
@darcyclarke
Copy link
Contributor

It sounds like you might be trying to reference multiple packages of the same name across different registries(?) If that is indeed the case, you should likely be defining the registries as scopes & then would be able to reference the package in your code/package.json accordingly (ref. https://docs.npmjs.com/cli/v8/using-npm/scope). Let me know if you're talking about something else though.

@darcyclarke darcyclarke removed the Agenda will be discussed at the Open RFC call label May 4, 2022
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