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

fix(config): allow .npmrc config to supersede yarn defaults #5825

Closed
wants to merge 1 commit into from

Conversation

thoov
Copy link
Contributor

@thoov thoov commented May 15, 2018

Summary

Running yarn config get registry within a project that contains a .npmrc which overrides the registry config key is not respected and instead the default yarn registry option is returned. Conceptually if you look at the code for getOption it first checks to see if the config exists within yarn and if not found it will check for that config within npm's config. However, the problem arises as the config property that is built up gets merged with yarns default values. This means that any config key that exists as a yarn default cannot be overwritten via .npmrc. This change differentiates yarn default configs and configs specified via .yarnrc. This allows the proper config fall back.

Test plan

  • mkdir /tmp/foobar
  • cd /tmp/foobar
  • echo 'registry=http://example.com' > .npmrc
  • yarn config get registry

Returns https://registry.yarnpkg.com/

  • yarn-local config get registry

Returns http://example.com/

Running `yarn config get registry` within a project that contains
a .npmrc which overrides the registry config key is not respected
and instead the default yarn registry option is returned. Conceptually
if you look at the code for `getOption` it first checks to see if
the config exists within yarn and if not found it will check for that
config within npm's config. However, the problem arises as the config
property that is built up gets merged with yarns default values. This
means that any config key that exists as a yarn default cannot be
overwritten via .npmrc. This change differencates yarn default configs
and configs specified via .yarnrc. This allows the proper config fall
back.
@thoov
Copy link
Contributor Author

thoov commented May 15, 2018

cc @stefanpenner

@BYK BYK requested review from rally25rs and imsnif May 23, 2018 10:20
@BYK
Copy link
Member

BYK commented May 23, 2018

#5812 also seems related.

@imsnif
Copy link
Member

imsnif commented May 25, 2018

Hey @thoov - thanks very much for this PR!
While it looks great, as @BYK mentioned, we've actually recently had a very similar patch that made us understand we'd like the fix to come in a different place. For details: #5812

I think right now @otaku is working on it, but if not and you wish to go for it yourself - I'd be happy to merge that future PR (and/or provide clarifications beforehand as needed). How does that sound?

EDIT: @thoov - if you'd like to work on this, it's yours. If not, I'll open an issue and we'll address this ourselves if there are no other takers.

@imsnif imsnif self-assigned this May 25, 2018
@stefanpenner
Copy link
Contributor

stefanpenner commented May 25, 2018

@imsnif is the guidance specifically this comment #5812 (comment)?

@imsnif
Copy link
Member

imsnif commented May 25, 2018

@stefanpenner - yep.

@thoov
Copy link
Contributor Author

thoov commented May 30, 2018

@imsnif Sorry I stepped away from this for a few days. I would gladly help out on implementing what you have described in #5812 (comment). Is someone working on that?

@imsnif
Copy link
Member

imsnif commented May 31, 2018

No worries, @thoov - to the best of my knowledge no-one is working on this specifically. However, there is a general issue about merging the two registries here: #5873

@arcanis - would it help out if we do as described here: #5812 (comment) ?

@arcanis
Copy link
Member

arcanis commented May 31, 2018

Yeah, I think it would be a good thing. I wonder if we should whitelist the options and only keep the ones that we are sure are safe, since they might have different type or interpretation depending on the package manager.

@imsnif
Copy link
Member

imsnif commented Jun 11, 2018

Hey @thoov - what do you think? Still feel like working on this?

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

Successfully merging this pull request may close these issues.

None yet

5 participants