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(builtin): set cwd before running yarn for yarn_install #1569

Merged
merged 1 commit into from
Jan 22, 2020

Conversation

gregmagolan
Copy link
Collaborator

@gregmagolan gregmagolan commented Jan 22, 2020

Also do the same for @nodejs//:yarn & @nodejs//:yarn_node_repositories targets.

This allows yarn to pickup the yarn-path attribute of .yarnrc which is only checked inside ${process.cwd()}/.yarnrc when yarn runs. Previously we ran yarn with --cwd which works for all other .yarnrc options except yarn-path.

PR Checklist

Please check if your PR fulfills the following requirements:

  • Tests for the changes have been added (for bug fixes / features)
  • Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Feature (please, look at the "Scope of the project" section in the README.md file)
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Documentation content changes
  • Other... Please describe:

What is the current behavior?

Issue Number: N/A

What is the new behavior?

Does this PR introduce a breaking change?

  • Yes
  • No

Other information

Also fix the same for @nodejs//:yarn & @nodejs//:yarn_node_repositories targets.

This allows yarn to pickup the `yarn-path` attribute of `.yarnrc` which is only checked inside `${process.cwd()}/.yarnrc` when yarn runs. Previously we running yarn with `--cwd` which works for all other `.yarnrc` options except `yarn-path`.
josephperrott added a commit to josephperrott/angular that referenced this pull request Jan 22, 2020
Rather than enforcing yarn versioning using `package.json`'s
engines value.  We can utilize yarn's `yarn-path` value to
ensure that the version of yarn used at execution time is
consistent for everyone who uses our repo.  This is the first
step in this wider vendoring process.  We will use this same
vendoring mechanism for CI after
bazel-contrib/rules_nodejs#1569 lands
josephperrott added a commit to josephperrott/angular that referenced this pull request Jan 22, 2020
Rather than enforcing yarn versioning using `package.json`'s
engines value.  We can utilize yarn's `yarn-path` value to
ensure that the version of yarn used at execution time is
consistent for everyone who uses our repo.  This is the first
step in this wider vendoring process.  We will use this same
vendoring mechanism for CI after
bazel-contrib/rules_nodejs#1569 lands
josephperrott added a commit to josephperrott/angular that referenced this pull request Jan 22, 2020
Rather than enforcing yarn versioning using `package.json`'s
engines value.  We can utilize yarn's `yarn-path` value to
ensure that the version of yarn used at execution time is
consistent for everyone who uses our repo.  This is the first
step in this wider vendoring process.  We will use this same
vendoring mechanism for CI after
bazel-contrib/rules_nodejs#1569 lands
Copy link
Collaborator

@alexeagle alexeagle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sigh more bash/batch wrapping, but we did it for npm already since it didn't have a

@gregmagolan gregmagolan merged commit d7083ac into bazel-contrib:master Jan 22, 2020
AndrewKushnir pushed a commit to angular/angular that referenced this pull request Jan 23, 2020
Rather than enforcing yarn versioning using `package.json`'s
engines value.  We can utilize yarn's `yarn-path` value to
ensure that the version of yarn used at execution time is
consistent for everyone who uses our repo.  This is the first
step in this wider vendoring process.  We will use this same
vendoring mechanism for CI after
bazel-contrib/rules_nodejs#1569 lands

PR Close #34902
AndrewKushnir pushed a commit to angular/angular that referenced this pull request Jan 23, 2020
Rather than enforcing yarn versioning using `package.json`'s
engines value.  We can utilize yarn's `yarn-path` value to
ensure that the version of yarn used at execution time is
consistent for everyone who uses our repo.  This is the first
step in this wider vendoring process.  We will use this same
vendoring mechanism for CI after
bazel-contrib/rules_nodejs#1569 lands

PR Close #34902
josephperrott added a commit to josephperrott/components that referenced this pull request Jan 27, 2020
Rather than enforcing yarn versioning using `package.json`'s
engines value.  We can utilize yarn's `yarn-path` value to
ensure that the version of yarn used at execution time is
consistent for everyone who uses our repo.  This is the first
step in this wider vendoring process.  We will use this same
vendoring mechanism for CI after
bazel-contrib/rules_nodejs#1569 lands
sonukapoor pushed a commit to sonukapoor/angular that referenced this pull request Feb 13, 2020
Rather than enforcing yarn versioning using `package.json`'s
engines value.  We can utilize yarn's `yarn-path` value to
ensure that the version of yarn used at execution time is
consistent for everyone who uses our repo.  This is the first
step in this wider vendoring process.  We will use this same
vendoring mechanism for CI after
bazel-contrib/rules_nodejs#1569 lands

PR Close angular#34902
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants