build: use bazel from node modules #16361
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
googlebot
added
the
cla: yes
devversion
force-pushed
the
build/use-bazel-from-node-modules
branch
2 times, most recently
from
cc73776 to
fa2961a
Compare
The goal of angular@2ce5ffd was to avoid the use of Bazel through the `node_modules` because it adds unnecessary code overhead, slows down CI and means that some tools need to be installed multiple times (such as `yarn`). Unfortunately when building a release with Bazel right now, the bazel workspace status script depends on the global `node` binary. This means that we need to bring in Node when running with the `--config=release` flag.. Since that causes inconsistent behavior and just complicates the setup, we are using Bazel through Yarn for now. Similar to how we did it for `angular/angular` with angular/angular@8fc4ae5.
devversion
force-pushed
the
build/use-bazel-from-node-modules
branch
from
fa2961a to
be866a1
Compare
devversion
added
pr: merge safe
target: patch
jelbourn
added
pr: lgtm
action: merge
andrewseguin
pushed a commit
that referenced
this pull request
Jul 2, 2019
The goal of 2ce5ffd was to avoid the use of Bazel through the `node_modules` because it adds unnecessary code overhead, slows down CI and means that some tools need to be installed multiple times (such as `yarn`). Unfortunately when building a release with Bazel right now, the bazel workspace status script depends on the global `node` binary. This means that we need to bring in Node when running with the `--config=release` flag.. Since that causes inconsistent behavior and just complicates the setup, we are using Bazel through Yarn for now. Similar to how we did it for `angular/angular` with angular/angular@8fc4ae5.
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The goal of 2ce5ffd was to avoid the use of Bazel through the
node_modulesbecause it adds unnecessary code overhead, slows down CI and means that
some tools need to be installed multiple times (such as
yarn). Unfortunatelywhen building a release with Bazel right now, the bazel workspace status script
depends on the global
nodebinary. This means that we need to bring in Nodewhen running with the
--config=releaseflag.. Since that causes inconsistent behaviorand just complicates the setup, we are using Bazel through Yarn for now. Similar to how
we did it for
angular/angularwith angular/angular@8fc4ae5.We need to revisit this overall approach in the future.. but for now this seems to be the
simplest approach and we don't want too much effort into this yet. Seems like a general
question for #dev-infra where we need to figure out the ideal approach.