This has a couple benefits:
- we now use a .bazelversion file rather than package.json to pin the version of bazel we want. This means even if you install bazel on your computer rather than via yarn, you'll still get a warning if your bazel version is wrong.
- you no longer end up downloading three copies of bazel due to bugs in both npm and yarn where they download all tarballs before checking the metadata to see which are usable on the local platform.
- bazelisk correctly handles the tools/bazel trick for wrapping functionality, which we want to use to instrument developer build latencies
PR Close#36078
ng_update_migrations will still access the global yarn cache on its `ng update` call and there is no way to avoid this that I can see but if no other integration tests access the global yarn cache then that one test can have free reign over it.
PR Close#35877
* it's tricky to get out of the runfiles tree with `bazel test` as `BUILD_WORKSPACE_DIRECTORY` is not set but I employed a trick to read the `DO_NOT_BUILD_HERE` file that is one level up from `execroot` and that contains the workspace directory. This is experimental and if `bazel test //:test.debug` fails than `bazel run` is still guaranteed to work as `BUILD_WORKSPACE_DIRECTORY` will be set in that context
* test //integration:bazel_test and //integration:bazel-schematics_test exclusively
* run "exclusive" and "manual" bazel-in-bazel integration tests in their own CI job as they take 8m+ to execute
```
//integration:bazel-schematics_test PASSED in 317.2s
//integration:bazel_test PASSED in 167.8s
```
* Skip all integration tests that are now handled by angular_integration_test except the tests that are tracked for payload size; these are:
- cli-hello-world*
- hello_world__closure
* add & pin @babel deps as newer versions of babel break //packages/localize/src/tools/test:test
@babel/core dep had to be pinned to 7.6.4 or else //packages/localize/src/tools/test:test failed. Also //packages/localize uses @babel/generator, @babel/template, @babel/traverse & @babel/types so these deps were added to package.json as they were not being hoisted anymore from @babel/core transitive.
NB: integration/hello_world__systemjs_umd test must run with systemjs 0.20.0
NB: systemjs must be at 0.18.10 for legacy saucelabs job to pass
NB: With Bazel 2.0, the glob for the files to test `"integration/bazel/**"` is empty if integation/bazel is in .bazelignore. This glob worked under these conditions with 1.1.0. I did not bother testing with 1.2.x as not having integration/bazel in .bazelignore is correct.
PR Close#33927
Previously, we needed to manually specify a ChromeDriver version to
download on CI that would be compatible with the browser version
provided by the docker image used to run the tests. This was kept in the
`CI_CHROMEDRIVER_VERSION_ARG` environment variable.
With recent commits, we use the browser provided by `puppeteer` and can
determine the correct ChromeDriver version programmatically. Therefore,
we no longer need the `CI_CHROMEDRIVER_VERSION_ARG` environment
variable.
NOTE:
There is still one place (the `bazel-schematics` integration project)
where a hard-coded ChromeDriver version is necessary. Since I am not
sure what is the best way to refactor the tests to not rely on a
hard-coded version, I left it as a TODO for a follow-up PR.
PR Close#35381
This allows us to update the version of the package in a single place for all tests.
Notable exemption of this is aio which currently doesn't depend on anything installed in the root.
PR Close#34002
Note: the @angular/bazel schematic now appends the package.json "script" field with 'ngcc --properties es2015 browser module main'. If there is an existing script field with ngcc then the schematic modifies it in place removing `--first-only` and `--create-ivy-entry-points`.
ViewEngine sources under node_modules need to be updated in-place for Bazel as it does not know how to use the `__ivy__` entry points that are created by the non-bazel `ngcc` command that is added to "scripts" :`ngcc --properties es2015 browser module main --first-only --create-ivy-entry-points`.
PR Close#33435
This commit removes `@angular-devkit/build-angular` from package.json
for a project that opts into Bazel. This is because the package adds a
dependency on node-sass, which is rejected by Bazel due to its absense.
This commit also appends to `scripts.postinstall` if it already exists.
This is needed because `ng new` in CLI v9 now automatically adds a
postinstall step for `ngcc`.
PR Close#32946
This commit switches the default value of the enableIvy flag to true.
Applications that run ngc will now by default receive an Ivy build!
This does not affect the way Bazel builds in the Angular repo work, since
those are still switched based on the value of the --define=compile flag.
Additionally, projects using @angular/bazel still use View Engine builds
by default.
Since most of the Angular repo tests are still written against View Engine
(particularly because we still publish VE packages to NPM), this switch
also requires lots of `enableIvy: false` flags in tsconfigs throughout the
repo.
Congrats to the team for reaching this milestone!
PR Close#32219
Before this change, user's tsconfig.json is cloned and some options
controlled by Bazel are removed otherwise Bazel would complain about:
```
WARNING: your tsconfig.json file specifies options which are overridden by Bazel:
- compilerOptions.target and compilerOptions.module are controlled by downstream dependencies, such as ts_devserver
- compilerOptions.typeRoots is always set to the @types subdirectory of the node_modules attribute
- compilerOptions.rootDir and compilerOptions.baseUrl are always the workspace root directory
```
Since the warning has been removed in rules_typescript/8d8d398, there's no
need to clone and backup tsconfig.json
PR Close#30877
nodejs rules 0.30.1 has new feature to symlink node_modules with yarn_install and bazel 0.26.0 includes new managed_directories feature which enables this
PR Close#30627
The bazel-schematics test could suffer from a version skew where new CLI projects were not yet using a new TS version, but Angular packages already were.
This caused the the `ngc` call in the added `postinstall` to run and fail: https://circleci.com/gh/angular/angular/283109
PR Close#29885
This commit makes the integration test for bazel-schematics more robust
by removing package.json.replace. Instead of replacing the file, the
test script now just overrides Angular packages with the local ones.
This commit also fixes running the test locally by providing default
argument for CI_CHROMEDRIVER_VERSION_ARG.
PR Close#28872
The logic to create additional files needed for Bazel are currently
hosted in `ng new`. Such files include the main.*.ts files needed
for AOT and a different angular.json to use Bazel builder, among others.
This commit refactors the logic into `ng add` so that it can be used to
perform the same modifications in an existing project. Users could do so
by running `ng add @angular/bazel`.
With this change, `ng new` effectively becomes an orchestrator that runs
the original `ng new` followed by `ng add @angular/bazel`.
PR Close#28436
By default, `webdriver-manager update` will download the latest
ChromeDriver version, which might not be compatible with the Chrome
version included in the [docker image used on CI], causing CI failures.
Previously, we used to pin the ChromeDriver version on CI in
[ngcontainer's Dockerfile][2]. This was accidentally broken in #26691,
while moving from ngcontainer to default CircleCI docker images.
This commit fixes the issue by pinning ChromeDriver to a known
compatible version.
[1]: bfd48d156d/.circleci/config.yml (L16)
[2]: bfd48d156d/tools/ngcontainer/Dockerfile (L63)
PR Close#28494
This commit fixes a bug in the Bazel builder in which the path to Bazel
executable is constructed using the project path. For non-default
project, the node_modules directory is actually one level above the
project path.
This PR fixes the bug by resolving node_modules with require.resolve().
It requires @bazel/bazel v0.22.1 because previous versions do not have
index.js or main field in package.json and would cause node module
resolution to fail.
This has been tested with both bazel and ibazel.
PR Close#28478
With the release of @angular/bazel v7.2.3, the npm install step right
after `ng new` installs this version. However there is a bug in the
builder which results in bazel executable not found.
This bug was not discovered before because the dependencies of the
project created by `ng new` are not pinned.
The fix is to pin the version of @angular/bazel to 7.2.2 which relies on
global installation of bazel.
PR Close#28460
yarn install was disabled in ng-new for Bazel schematics because
Bazel manages its own node_modules dependencies and therefore
there is no need to install dependencies twice.
However, the first yarn install is needed for `ng` commands to work,
most notably `ng build`.
This commit restores the original behavior.
PR Close#28381
The integration test for bazel-schematics installs Angular in
two different locations:
1. Bazel workspace
2. package.json -> fetched from npm
Pull request #28142 changes the test to always install (1) from
source. This breaks when there's a major version bump since the
versions locally and the version in package.json no longer match.
This change updates package.json to fetch @angular/* packages
locally as well.
PR Close#28194
The current integration test for Bazel schematics downloads a
published version of Angular as required by the http_archive
rule in the CLI created WORKSPACE.
However, this makes the test less useful because it does not
actually test any changes to the Angular repo at source.
This PR replaces the http_archive method in the WORSPACE
with local_repository so that any local changes to the Angular
repo are tested accordingly.
With Typescript 3.2, the file e2e/src/app.po.ts generated by CLI
no longer compiles under Bazel due to missing type annotations.
A temporary file is placed in the integration/bazel-schematics
directory while the change is pending in CLI repo.
https://github.com/angular/angular-cli/pull/13406
PR Close#28061
The build and test progress logs make the CI log output so long that it
can't be displayed in the UI and one has to download and view the file
locally instead. This makes it harder to get to the interesting lines,
such as error messages.
Similar to #26869, but for the `bazel-schematics` integration project.
PR Close#27934
Relative imports in Typescript files only work when module_name is
defined in ts_library (when run in Node.js).
See issue https://github.com/bazelbuild/rules_typescript/issues/360
With that fixed, `ng test` now works.
`ng build` requires `node_modules` to be available in the project
directory, so it's not usable yet. Running `yarn` in project directory
does not work because of postinstall version check.
PR Close#27715
Alex Eagle
Greg Magolan
George Kalpakas
Igor Minar
Filipe Silva
Keen Yee Liau
Alex Rickabaugh
Keen Yee Liau