* No longer depends on a custom CircleCI docker image that comes with Bazel pre-installed. Since Bazel is now available through NPM, we should be able to use the version from `@bazel/bazel` in order to enforce a consistent environment on CI and locally.
* This also reduces the amount of packages that need to be published (ngcontainer is removed)
PR Close#26691
This makes yarn_install of ngdeps under Bazel faster, since we don't need many of the large dependencies.
It's important because downstream angular/bazel users will observe the same install time.
PR Close#26691
We are close enough to blacklist a few test targets, rather than whitelist targets to run...
Because bazel rules can be composed of other rules that don't inherit tags automatically,
I had to explicitly mark all of our ts_library and ng_module targes with "ivy-local" and
"ivy-jit" tags so that we can create a query that excludes all fixme- tagged targets even
if those targets are composed of other targets that don't inherit this tag.
This is the updated overview of ivy related bazel tags:
- ivy-only: target that builds or runs only under ivy
- fixme-ivy-jit: target that doesn't yet build or run under ivy with --compile=jit
- fixme-ivy-local: target that doesn't yet build or run under ivy with --compile=local
- no-ivy-jit: target that is not intended to build or run under ivy with --compile=jit
- no-ivy-local: target that is not intended to build or run under ivy with --compile=local
PR Close#26471
This lets Angular Bazel users install our transitive deps, rather than have to list them in their WORKSPACE file.
If they want a different version of one of these deps, they just need to install it before calling rules_angular_dependencies.
PR Close#26488
Add following to your `~/.bazelrc`. This will run the build faster locally
(outside of sandbox), but continue running the builds with sandboxing
on CI.
```
build --spawn_strategy=standalone --strategy=ESM5=sandboxed
```
PR Close#25870
This is needed to let ts_compile_actions take explicit list of srcs and deps to generate tsc actions from another rule. This is no-op for ngc for now.
PR Close#25558
This turns on generation of ngfactory.js files when compiling in Ivy
mode in g3. They're not turned on for Bazel users as there appears to
be a strange interaction with the way our tests run in Bazel mode.
PR Close#25392
compile_strategy() is used to decide whether to build Angular code
using ngc (legacy) or ngtsc (local). In order for g3 BUILD rules
to switch properly and allow testing of Ivy in g3, they need to
import this function.
This commit removes the _ prefix which allows the function to be
imported.
PR Close#25080
It specifies --no-sandbox flag when running the protractor tests as
root. This is needed for running the tests inside a docker container.
PR Close#24906
This change turns on preserve-symlinks in nodejs to verify hermeticity of the Angular build.
BREAKING CHANGE: Use of @angular/bazel rules now requires calling ng_setup_workspace() in your WORKSPACE file.
For example:
local_repository(
name = "angular",
path = "node_modules/@angular/bazel",
)
load("@angular//:index.bzl", "ng_setup_workspace")
ng_setup_workspace()
PR Close#24881
With these changes, the types are a little stricter now and also not
compatible with Protractor's jasmine-like syntax. So, we have to also
use `@types/jasminewd2` for e2e tests (but not for non-e2e tests).
I also had to "augment" `@types/jasminewd2`, because the latest
typings from [DefinitelyTyped][1] do not reflect the fact that the
`jasminewd2` version (v2.1.0) currently used by Protractor supports
passing a `done` callback to a spec.
[1]: 566e039485/types/jasminewd2/index.d.ts (L9-L15)Fixes#23952Closes#24733
PR Close#19904
Previously the repo was depending on an old version of build optimizer.
This change updates to the latest (an RC release in the CLI package).
Additionally, this changes the behavior of ng_rollup_bundle to apply
the optimizer to ngtsc compiled code, and configures it to treat the
@angular/compiler package as side-effect-free.
This results in a substantial size reduction of ngtsc compiled code.
PR Close#24677
This commit builds out enough of the JIT compiler to render
//packages/core/test/bundling/todo, and allows the tests to run in
JIT mode.
To play with the app, run:
bazel run --define=compile=jit //packages/core/test/bundling/todo:prodserver
PR Close#24138
Bazel has a restriction that a single output (eg. a compiled version of
//packages/common) can only be produced by a single rule. This precludes
the Angular repo from having multiple rules that build the same code. And
the complexity of having a single rule produce multiple outputs (eg. an
ngc-compiled version of //packages/common and an Ivy-enabled version) is
too high.
Additionally, the Angular repo has lots of existing tests which could be
executed as-is under Ivy. Such testing is very valuable, and it would be
nice to share not only the code, but the dependency graph / build config
as well.
Thus, this change introduces a --define flag 'compile' with three potential
values. When --define=compile=X is set, the entire build system runs in a
particular mode - the behavior of all existing targets is controlled by
the flag. This allows us to reuse our entire build structure for testing
in a variety of different manners. The flag has three possible settings:
* legacy (the default): the traditional View Engine (ngc) build
* local: runs the prototype ngtsc compiler, which does not rely on global
analysis
* jit: runs ngtsc in a mode which executes tsickle, but excludes the
Angular related transforms, which approximates the behavior of plain
tsc. This allows the main packages such as common to be tested with
the JIT compiler.
Additionally, the ivy_ng_module() rule still exists and runs ngc in a mode
where Ivy-compiled output is produced from global analysis information, as
a stopgap while ngtsc is being developed.
PR Close#24056
`ng.performCompilation` can return an `undefined` program, which is not handled by ngc-wrapped.
Avoid crashing by checking for the error return and returning the diagnostics.
PR Close#23468
All our package labels are `npm_package` so the bazel build reports a bunch of identical actions running, like
```
Angular Packaging: rolling up npm_package; 31s darwin-sandbox
Angular Packaging: rolling up npm_package; 30s darwin-sandbox
Angular Packaging: rolling up npm_package; 29s darwin-sandbox
Angular Packaging: rolling up npm_package; 27s darwin-sandbox
Angular Packaging: rolling up npm_package; 26s darwin-sandbox
Angular Packaging: rolling up npm_package; 23s darwin-sandbox
Angular Packaging: rolling up npm_package; 19s darwin-sandbox
Angular Packaging: rolling up npm_package; 11s darwin-sandbox
```
PR Close#23318
This commit modifies the compilation to emit metadata.json files when
compiled under Blaze. The default behavior of ngc is to emit metadata
only when the --flatModuleOutFile flag is specified, but this mode
is not used in Blaze.
Emitting metadata for individual Angular components is needed for
Angular Language Service to work with projects compiled with Blaze.
PR Close#23049
Greg Magolan
Misko Hevery
Alan Agius
Paul Gschwendtner
Alex Eagle
Igor Minar
Alex Eagle
Pete Bacon Darwin
Greg Estren
Vikram Subramanian
Wei Huang
Victor Berchet
Martin Probst
Ben Lesh
Alex Rickabaugh
Fabian Wiles
mrmeku
George Kalpakas
Lucas Sloan
Jeremy Elbourn
Keen Yee Liau