7.1 KiB
Building and Testing Angular
This document describes how to set up your development environment to build and test Angular.
It also explains the basic mechanics of using git
, node
, and yarn
.
See the contribution guidelines if you'd like to contribute to Angular.
Prerequisite Software
Before you can build and test Angular, you must install and configure the following products on your development machine:
-
Git and/or the GitHub app (for Mac or Windows); GitHub's Guide to Installing Git is a good source of information.
-
Node.js, (version specified in the engines field of
package.json
) which is used to run a development web server, run tests, and generate distributable files. -
Yarn (version specified in the engines field of
package.json
) which is used to install dependencies. -
Java Development Kit which is used to execute the selenium standalone server for e2e testing.
Getting the Sources
Fork and clone the Angular repository:
- Login to your GitHub account or create one by following the instructions given here.
- Fork the main Angular repository.
- Clone your fork of the Angular repository and define an
upstream
remote pointing back to the Angular repository that you forked in the first place.
# Clone your GitHub repository:
git clone git@github.com:<github username>/angular.git
# Go to the Angular directory:
cd angular
# Add the main Angular repository as an upstream remote to your repository:
git remote add upstream https://github.com/angular/angular.git
Installing NPM Modules
Next, install the JavaScript modules needed to build and test Angular:
# Install Angular project dependencies (package.json)
yarn install
Building
To build Angular run:
./scripts/build-packages-dist.sh
- Results are put in the
dist/packages-dist
folder.
Running Tests Locally
Bazel is used as the primary tool for building and testing Angular. Building and testing is incremental with Bazel, and it's possible to only run tests for an individual package instead of for all packages. Read more about this in the BAZEL.md document.
You should execute all test suites before submitting a PR to GitHub:
yarn bazel test packages/...
Note: The first test run will be much slower than future runs. This is because future runs will benefit from Bazel's capability to do incremental builds.
All the tests are executed on our Continuous Integration infrastructure. PRs can only be merged if the code is formatted properly and all tests are passing.
Formatting your source code
Angular uses clang-format to format the source code. If the source code is not properly formatted, the CI will fail and the PR cannot be merged.
You can automatically format your code by running:
yarn gulp format
: re-format only edited source code.yarn gulp format:all
: format all source code
A better way is to set up your IDE to format the changed file on each file save.
VS Code
- Install Clang-Format extension for VS Code.
- It will automatically pick up the settings from
.vscode/settings.json
. If you haven't already, create asettings.json
file by following the instructions here.
WebStorm / IntelliJ
- Install the ClangFormatIJ plugin
- Open
Preferences->Tools->clang-format
- Find the field named "PATH"
- Add
<PATH_TO_YOUR_WORKSPACE>/angular/node_modules/clang-format/bin/<OS>/
where the OS options are:darwin_x64
,linux_x64
, andwin32
.
Vim
- Install Vim Clang-Format.
- Create a project-specific
.vimrc
in your Angular directory containing
let g:clang_format#command = '$ANGULAR_PATH/node_modules/.bin/clang-format'
where $ANGULAR_PATH
is an environment variable of the absolute path of your Angular directory.
Linting/verifying your source code
You can check that your code is properly formatted and adheres to coding style by running:
$ yarn gulp lint
Publishing snapshot builds
When a build of any branch on the upstream fork angular/angular is green on CircleCI,
it automatically publishes build artifacts
to repositories in the Angular org, eg. the @angular/core
package is published to
http://github.com/angular/core-builds.
You may find that your un-merged change needs some validation from external participants.
Rather than requiring them to pull your Pull Request and build Angular locally, you can
publish the *-builds
snapshots just like our CircleCI build does.
First time, you need to create the GitHub repositories:
$ export TOKEN=[get one from https://github.com/settings/tokens]
$ CREATE_REPOS=1 ./scripts/ci/publish-build-artifacts.sh [GitHub username]
For subsequent snapshots, just run
$ ./scripts/ci/publish-build-artifacts.sh [GitHub username]
The script will publish the build snapshot to a branch with the same name as your current branch, and create it if it doesn't exist.
Bazel support
IDEs
VS Code
- Install Bazel extension for VS Code.
WebStorm / IntelliJ
- Install the Bazel plugin
- You can find the settings under
Preferences->Other Settings->Bazel Settings
It will automatically recognize *.bazel
and *.bzl
files.
Remote Build Execution and Remote Caching
Bazel builds in the Angular repository use a shared http cache. When a build occurs a hash of the inputs is computed and checked against available outputs in the shared http cache. If an output is found, it is used as the output for the build action rather than performing the build locally.
Remote Build Execution and uploading to the Remote Cache requires authentication as a google.com or angular.io account.
--config=remote-http-caching flag
The --config=remote-http-caching
flag can be added to enable uploading of build results to the shared http cache. This flag
can be added to the .bazelrc.user
file using the script at scripts/local-dev/setup-rbe.sh
.
--config=remote flag
The --config=remote
flag can be added to enable remote execution of builds. This flag can be added to
the .bazelrc.user
file using the script at scripts/local-dev/setup-rbe.sh
.