cargdev/angular
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

build: upgrade angular build, integration/bazel and @angular/bazel package to rule_nodejs 2.2.0 (#39182)

Browse Source 
Updates to rules_nodejs 2.2.0. This is the first major release in 7 months and includes a number of features as well
as breaking changes.

Release notes: https://github.com/bazelbuild/rules_nodejs/releases/tag/2.0.0

Features of note for angular/angular:

* stdout/stderr/exit code capture; this could be potentially be useful

* TypeScript (ts_project); a simpler tsc rule that ts_library that can be used in the repo where ts_library is too
  heavy weight

Breaking changes of note for angular/angular:

* loading custom rules from npm packages: `ts_library` is no longer loaded from `@npm_bazel_typescript//:index.bzl`
  (which no longer exists) but is now loaded from `@npm//@bazel/typescript:index.bzl`

* with the loading changes above, `load("@npm//:install_bazel_dependencies.bzl", "install_bazel_dependencies")` is
  no longer needed in the WORKSPACE which also means that yarn_install does not need to run unless building/testing
  a target that depends on @npm. In angular/angular this is a minor improvement as almost everything depends on @npm.

* @angular/bazel package is also updated in this PR to support the new load location; Angular + Bazel users that
  require it for ng_package (ng_module is no longer needed in OSS with Angular 10) will need to load from
  `@npm//@angular/bazel:index.bzl`. I investigated if it was possible to maintain backward compatability for the old
  load location `@npm_angular_bazel` but it is not since the package itself needs to be updated to load from
  `@npm//@bazel/typescript:index.bzl` instead of `@npm_bazel_typescript//:index.bzl` as it depends on ts_library
  internals for ng_module.

* runfiles.resolve will now throw instead of returning undefined to match behavior of node require

Other changes in angular/angular:

* integration/bazel has been updated to use both ng_module and ts_libary with use_angular_plugin=true.
  The latter is the recommended way for rules_nodejs users to compile Angular 10 with Ivy. Bazel + Angular ViewEngine is
  supported with @angular/bazel <= 9.0.5 and Angular <= 8. There is still Angular ViewEngine example on rules_nodejs
  https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular_view_engine on these older versions but users
  that want to update to Angular 10 and are on Bazel must switch to Ivy and at that point ts_library with
  use_angular_plugin=true is more performant that ng_module. Angular example in rules_nodejs is configured this way
  as well: https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular. As an aside, we also have an
  example of building Angular 10 with architect() rule directly instead of using ts_library with angular plugin:
  https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular_bazel_architect.

NB: ng_module is still required for angular/angular repository as it still builds ViewEngine & @angular/bazel
also provides the ng_package rule. ng_module can be removed in the future if ViewEngine is no longer needed in
angular repo.

* JSModuleInfo provider added to ng_module. this is for forward compat for future rules_nodejs versions.

PR Close #39182
This commit is contained in:
Greg Magolan
2020-06-25 01:32:41 -07:00
committed by atscott
parent b417dd7b9c
commit 7628c36f49
63 changed files with 833 additions and 536 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
tools/npm_integration_test/test_runner.js
View File

@ -188,8 +188,15 @@ class TestRunner {
if (binary.startsWith('external/')) {
binary = `../${binary.substring('external/'.length)}`;
}
const runfilesBinary = runfiles.resolveWorkspaceRelative(binary);
binary = fs.existsSync(runfilesBinary) ? runfilesBinary : binary;
try {
// Attempt to resolve runfiles location if command is expected to
// be in runfiles. For example, $(rootpath @nodejs//:yarn_bin)
const runfilesBinary = runfiles.resolveWorkspaceRelative(binary);
binary = (runfilesBinary && fs.existsSync(runfilesBinary)) ? runfilesBinary : binary;
} catch (e) {
// If resolveWorkspaceRelative then command is likely a built-in
// such as 'mkdir' or 'rm'
}
log(`running test command ${this.successful + 1} of ${this.config.commands.length}: '${
binary} ${args.join(' ')}' in '${this.testRoot}'`);
const spawnedProcess = spawnSync(binary, args, {cwd: this.testRoot, stdio: 'inherit'});