9dd3f0344f
* build: disconnect `@npm` workspace from main project This will speed up significantly as we don't need to fetch all dependencies again just for the `@npm` repository that is at this point only leveraged by the `ng_package` rule for some of its dependencies. This commit allows us to drop the `yarn.lock` and Aspect lock files, and allows us to independently migrate `ng_package` to `rules_js`. It also allows us to drop the `_rjs` TS interop layer in follow-up commits. * build: drop `_rjs` suffix from `ts_project` targets We don't need the `ts_project` interop in principle at this point. We only have one remaining instance left for the SSR `ng_package` integration. This commit cleans up all usages. * build: remove yarn * build: avoid duplicated dependencies at top-level `rules_js` seems to be sensitive if there are similar versions of the same package installed, but with differently matched peer dependencies. This is fine because we can (and should long-term) move those dependencies to their package-local `package.json` files. This commit unblocks the migration and highlights how we can move deps to the individual packages in the future. * build: update checkout github action This will allow us to use pnpm. * build: update node to avoid strict-engines error caused by `npm` Avoids: ``` Lockfile is up to date, resolution step is skipped ERR_PNPM_UNSUPPORTED_ENGINE Unsupported environment (bad pnpm and/or Node.js version) Your Node version is incompatible with "npm@11.2.0". Expected version: ^20.17.0 || >=22.9.0 Got: v20.11.1 ``` Note that we won't update the WORKSPACE test version as that would mean we need to update the Node engines for shipped packages; and we can't do this right now without introducing a breaking change. * build: fix missing dependency for spec bundling The beasties JS sources weren't available for bundling in the `bazel-bin`, and this surfaced in RBE. This commit fixes this.
3.7 KiB
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:
pnpm bazel test --config=debug //packages/angular/cli:angular-cli_test
# Also disable reruns of failing tests that were marked as flaky:
pnpm bazel test --config=debug --config=no-sharding //packages/angular/cli:angular-cli_test