-
-
Notifications
You must be signed in to change notification settings - Fork 44
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
Adds support for installing a single package from a private repo #60
base: master
Are you sure you want to change the base?
Adds support for installing a single package from a private repo #60
Conversation
…y / Adds support to pass Basic authentication as token.
Thanks! I will review it in the next days. |
Thanks @davideicardi , unfortunately I can't modify the repo settings as was configured like this per company policy. I hope this PR can help this scenario and other ones. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From a code design perspective I would prefer to leave the installFromNpm
function as is.
Also because I suspect that this design doesn't allow you to install a child dependency from your custom registry. Let's say that you have module A inside your custom registry and it dependes on module B and C. Where B is inside default NPM registry but C is inside your custom registry. My fealing is that with this solution C cannot be installed. Right?
Maybe a better solution is to have a special NpmRegistryClient
implementation that internally forward the requests to multiple NpmRegistryClient
. Something similar to the Composite Pattern. We can have a MultiNpmRegistryClient
that accepts a list of children: Array[NpmRegistryClient]
.
If a module is not present in the first repository then the second repository is used and so on ...
What do you think?
if(username && password){ | ||
auth = Buffer.from(username + ":" + password).toString("base64"); | ||
} else { | ||
auth = username; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What kind of authentication is with just the username? Maybe we should create a dedicated auth flow?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@davideicardi , that sounds good, I'll find a way were we can scope out NPM components.
Also, I'll modify this code with a best way to handle the scenario where we already have the base64 key from the consumer.
This PR adds support for installing an NPM package from a private repository while installing all other packages from another repo. This PR also allows passing the encoded token to basic authentication in the event we already have it as base64.
Scenario to cover: A package has been pushed to a private repo. While installing, the NPM package needs to be installed from the private repo while the dependencies needs to come from the default public repository.