Skip to content

Latest commit

 

History

History
79 lines (58 loc) · 4.03 KB

bazel.md

File metadata and controls

79 lines (58 loc) · 4.03 KB

Yarn Workspaces

The package architecture of angular-cli repository is originally setup using yarn workspaces. This means the dependencies of various package.json in the repository are linked and installed together.

Bazel

Since then, Bazel was introduced to manage some of the build dependencies in angular-cli repo. However, Bazel does not yet support yarn workspaces, since it requires laying out more than one node_modules directory. In this mixed mode, developers ought to take extra care to synchronize the dependencies.

Since the yarn_install rule that installs all NPM dependencies in this repository only reads from the root package.json, every Bazel target that depends on packages downloaded from the NPM registry will need to have the dependency declared in the root package.json.

In addition, if the dependency is also needed at runtime (non-dev dependencies), the dependency on the individual package's package.json has to be updated as well. This is to ensure that when users download a published version from NPM, they will be able to install all dependencies correctly without Bazel. It is the responsibility of the developer to keep both package.json in sync.

Windows support

In general, any sort of node file lookup on Bazel should be subject to require.resolve. This is how rules_nodejs resolves paths using the Bazel runfiles mechanism, where a given Bazel target only has access to outputs from its dependencies.

In practice, this does not make a lot of difference on Linux. A symlink forest is laid down where the target is going to actually run, and mostly the files are resolved correctly whether you use require.resolve or not because the files are there.

On Windows though, that's a stricter. Bazel does not lay down a symlink forest on windows by default. If you don't use require.resolve, it's still possible to correctly resolve some files, like outputs from other rules. But other files, like node modules dependencies and data files, need to be looked up in the runfiles.

Since the requirement is quite lax on Linux but quite strict on windows, what ends up happening is that lack of require.resolve calls go unnoticed until someone tries to run things on Windows, at which point it breaks.

Debugging jasmine_node_test

On Linux, Bazel tests will run under a sandbox for isolation. You can turn off this sandbox by adding the local = True attribute to the rule. You can also force local execution by passing --test_output=streamed.

Then you will find the intermediate test files in bazel-out/k8-fastbuild/bin, followed by the test target path.

Tests that are sharded, via the shard_count attribute, can fail if you reduce the number of tests or focus only a few. This will cause some shards to execute 0 tests, which makes the exit with an error code.

Tests that are marked as flaky, via the flaky attribute, will repeat when they fail. This will cause any focused test to be repeated multiple time, since the presence of focused tests causes jasmine to exit with a non-zero exit code.

While testing, you can remove the shard_count attribute to prevent sharding and the flaky attribute to prevent repetition. Setting --test_output=streamed will disable sharding and --flaky_test_attempts=1 will disable the reruns of tests that have been marked as flaky.

The .bazelrc includes a config for running tests with remote debugging enabled:

yarn bazel test --config=debug //packages/angular/cli:angular-cli_test
# Also disable reruns of failing tests that were marked as flaky:
yarn bazel test --config=debug --config=no-sharding //packages/angular/cli:angular-cli_test

NB: For a few tests, sandbox is required as otherwise the rules_nodejs linker symlinks will conflict with the yarn workspace symlinks in node_modules.

Issues

  1. Yarn workspaces is not compatible with Bazel-managed deps (#12736)