-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
use configured global registry for library lookup #5840
use configured global registry for library lookup #5840
Conversation
Hmm it's also worth considering scoped dependencies in this case. I might have to do another pass at this to search the rc files for scopes that match. There doesn't appear to be any scoped registry handling in the RegistryFinder. |
I moved |
Just for my understanding the global registry == private registry ? |
@honeyankit yes typically, although conceivably it could point to anything. In npm and yarn, you can configure a registry globally or scoped. In npm that looks like:
|
Are we concerned with changing the default behavior for all dependabot users? I think this seems like the more correct behavior in general, but this does change how dependabot currently behaves in a way users might not expect. Should we put this behind a feature flag? |
@pavera I'm not concerned. This code path only influences whether the update strategy is widen ranges or bump versions. Dependabot is already using the private registry for all the other calls. So folks who don't use an .npmrc won't see a difference. Those that have a registry defined are likely to see more correct behavior, especially those who've published to the private registry, as we can now correctly identify a library that has been published there. |
Context
Dependabot honors an
.npmrc
or.yarnrc
file to set the global registry. When a global registry is present in one of these files, Dependabot shouldn't make calls to registry.npmjs.org. This library check was doing just that!Approach
At first I tried using the RegistryFinder's
registry
method, but that method assumes you're giving it a dependency. The library check is checking the registry for the project itself, and thus won't be present in the dependencies of the project when RegistryFinder goes to look for it.So rather than change the
registry
method, I exposed theglobal_registry
method so I could use it in the library check. I also modified it to stop stripping the protocol, since it is valid for enterprises to have an internal registry that isn't secured by TLS. I put the stripping in thefirst_registry_with_dependency_details
which was the only place it was used.