The `@angular/compiler` package currently contains the logic for determining whether
given queries are used statically or dynamically. This logic would be necessary in order
to build a schematic that leverages the Angular compiler API's in order to simulate the
query timing based on what ViewEngine computed at compilation-time/runtime.
Exporting the logic that is necessary to detect the timing should not affect the public
API as the `@angular/compiler` package is denoted as private in `PUBLIC_API.md`
PR Close#29815
In order to support multiple strategies for detecting the query timing, the
query usage logic has been moved into a query usage strategy.
PR Close#29815
`NodeJsSyncHost` is no longer provided by BuilderContext in
architect v2, and its usage caused subtle path resolution issues
in Windows.
This PR cleans up `@angular/bazel` builder to use all native path
and fs methods.
PR Close#29796
Plural ICU expressions depend on the locale (different languages have different plural forms). Until now the locale was hard coded as `en-US`.
For compatibility reasons, if you use ivy with AOT and bootstrap your app with `bootstrapModule` then the `LOCALE_ID` token will be set automatically for ivy, which is then used to get the correct plural form.
If you use JIT, you need to define the `LOCALE_ID` provider on the module that you bootstrap.
For `TestBed` you can use either `configureTestingModule` or `overrideProvider` to define that provider.
If you don't use the compat mode and start your app with `renderComponent` you need to call `ɵsetLocaleId` manually to define the `LOCALE_ID` before bootstrap. We expect this to change once we start adding the new i18n APIs, so don't rely on this function (there's a reason why it's a private export).
PR Close#29249
Prior to this change, element attributes annotated with i18n- prefix were removed from element attribute list and processed separately by i18n-specific logic. This behavior is causing issues with directive matching, since attributes are not present in the list of attrs for matching purposes. This commit updates i18n logic to retain attributes in the main attribute list, thus allowing directive matching logic to work correctly.
PR Close#29856
In order to be backwards compatible with View Engine, Ivy should log
errors by default in the TestBed error handler rather than re-throwing
them. Re-throwing the errors is a breaking change that causes issues with
libraries like ngrx that have async behavior and custom error handling.
This logging approach has issues (for both VE and Ivy) because it can allow
tests to pass inappropriately if errors are thrown inside listeners. However,
since re-throwing would be breaking and requires a larger redesign, we should
wait until post-Ivy.
PR Close#29853
Previously, this check was done with bracket property access on the
global object: global['goog']
This will not be minified when Closure compiles this code, which:
1) breaks, because 'goog' will have been minified but the check won't have
taken that into consideration
2) causes build failures in g3, because the actual property 'goog' is
forbidden in some published JS code (to ensure obfuscation).
A TODO is added to validate that this logic is correct, as it's difficult to
test within the Angular repo.
PR Close#29873
The `Δ` caused issue with other infrastructure, and we are temporarily
changing it to `ɵɵ`.
This commit also patches ts_api_guardian_test and AIO to understand `ɵɵ`.
PR Close#29850
The code failed presubmit in google3 because the original ts config was not as strict
as the one used elsewhere in angular/angular and google3.
PR Close#29843
So far using runtime i18n with ivy meant that you needed to use Closure and `goog.getMsg` (or a polyfill). This PR changes the compiler to output both closure & non-closure code, while the unused option will be tree-shaken by minifiers.
This means that if you use the Angular CLI with ivy and load a translations file, you can use i18n and the application will not throw at runtime.
For now it will not translate your application, but at least you can try ivy without having to remove all of your i18n code and configuration.
PR Close#28689
Queries can technically be also accessed within component templates
e.g.
```html
<my-comp [binding]="myQuery"></my-comp>
```
In that case the query with the property "myQuery" is accessed
statically and needs to be marked with `static: true`. There are
other edge cases that need to be handled as the template property
read doesn't necessarily resolve to the actual query property.
For example:
```html
<foo #myQuery></foo>
<my-comp [binding]="myQuery"></my-comp>
```
In this scenario the binding doesn't refer to the actual query
because the template reference variable takes precedence. The
query doesn't need to be marked with "static: true" this time.
This commit ensures that the `static-query` migration schematic
now handles this cases properly. Also template property reads
that access queries from within a `<ng-template>` are ignored
as these can't access the query before the view has been initialized.
Resolves FW-1216
PR Close#29713
- Removes `@publicApi` annotation from ivy instructions
- Adds new `@codeGenApi` annotation to ivy instructions
- Updates ts_api_guardian to support the new annotation properly
PR Close#29820
Currently in Ivy we pass both the raw and parsed selectors to the projectionDef instruction, because the parsed selectors are used to match most nodes, whereas the raw ones are used to match against nodes with the ngProjectAs attribute. The raw selectors add a fair bit of code that won't be used in most cases, because ngProjectAs is somewhat rare.
These changes rework the compiler not to output the raw selectors in the projectionDef, but to parse the selector in ngProjectAs and to store it on the TAttributes. The logic for matching has also been changed so that it matches the pre-parsed ngProjectAs selector against the list of projection selectors.
PR Close#29578
- Adds the instructions
- Adds tests for all instructions
- Adds TODO to remove all tests when we are able to test this with TestBed after the compiler is updated
PR Close#29576
- moves the property instruction to its own file
- moves shared functions that should not be public to the existing `shared.ts` file.
- adds the export of `property.ts` to `all.ts`
PR Close#29576
While investigating styling performance regressions, it was discovered
that a single `fn(...args)` operation was causing a performance hit
because the generated es5 `__spread` operation uses `[].concat` and
reads from the `arguments` values (which are not very efficient). This
patch changes that around to use `fn.apply` instead.
PR Close#29795
Currently the `static-query` and `template-var-assignment` schematic only runs
for `8.0.0` which does not include any betas or release candidates. We want to
run the schematic in the beta's and RC in order to get early feedback about the
schematics. Enabling it promptly with V8 stable release can result in accidental
breakages that we would like to fix/identify before.
PR Close#29735
Queries can not only be accessed within derived classes, but also in
the super class through abstract methods. e.g.
```
abstract class BaseClass {
abstract getEmbeddedForm(): NgForm {}
ngOnInit() {
this.getEmbeddedForm().doSomething();
}
}
class Subclass extends BaseClass {
@ViewChild(NgForm) form: NgForm;
getEmbeddedForm() { return this.form; }
}
```
Same applies for abstract properties which are implemented in the base class
through accessors. This case is also now handled by the schematic.
Resolves FW-1213
PR Close#29688
Currently the static-query schematic is not able to properly handle
call expressions that pass function declarations that access a given
query. e.g.
```ts
ngOnInit() {
this._callFunction(() => this.myQuery.doSomething());
}
_callFunction(cb: any) { cb(); }
```
In that case the passed function is executed synchronously in
the "ngOnInit" lifecycle and therefore the query needs to be
detected as "static".
We can fix this by keeping track of the current function context
and using it to resolve identifiers to the passed arguments.
PR Close#29663
Currently we only check getters for property access expressions. This is wrong
because property access expressions do not always cause the "getter" to be
triggered. e.g.
```ts
set a() {...}
get a() {...}
ngOnInit() {
this.a = true;
}
```
In that case the schematic currently incorrectly checks the "getter", while this is a binary
expression and the property access is used as left-side of the binary expression. In that
case we need to check the setter declaration of the property and not the "getter". In order
to fix this, we need to also check `ts.BinaryExpression` nodes and check getters/setters
based on the used operator token. There are three types of binary expressions:
1) Value assignment (using `=`). In that case only the setter is triggered.
2) Compound assignment (e.g. using `+=`). In that case `getter` and `setter` are triggered.
3) Comparison (e.g. using `===`). In that case only the getter is triggered.
PR Close#29663
Fixes the creation mode block not being run on components which have been detached from change detection.
This PR resolves FW-1217.
Fixes#29645.
PR Close#29741
Fixes Ivy not throwing an error if it runs into an invalid property binding on a container node (e.g. `<div *ngFor="let row of rows">` instead of `<div *ngFor="let row if rows">`).
This PR resolves FW-1219.
PR Close#29691
In order to optimize performance for styling-related operations in
Angular, debug counters need to be introduced. This patch adds various
counters to ngDevMode which are fired each time a styling-related
binding is updated.
PR Close#29579
Previously we always walked the whole folder tree looking for
entry-points before we tested whether a target package had been
processed already. This could take >10secs!
This commit does a quick check of the target package before doing
the full walk which brings down the execution time for ngcc in this
case dramatically.
```
$ time ./node_modules/.bin/ivy-ngcc -t @angular/common/http/testing
Compiling @angular/core : fesm2015 as esm2015
Compiling @angular/core : fesm5 as esm5
Compiling @angular/core : esm2015 as esm2015
Compiling @angular/core : esm5 as esm5
Compiling @angular/common/http : fesm2015 as esm2015
Compiling @angular/common/http : fesm5 as esm5
Compiling @angular/common/http : esm2015 as esm2015
Compiling @angular/common/http : esm5 as esm5
Compiling @angular/common/http/testing : fesm2015 as esm2015
Compiling @angular/common/http/testing : fesm5 as esm5
Compiling @angular/common/http/testing : esm2015 as esm2015
Compiling @angular/common/http/testing : esm5 as esm5
real 0m19.766s
user 0m28.533s
sys 0m2.262s
```
```
$ time ./node_modules/.bin/ivy-ngcc -t @angular/common/http/testing
The target entry-point has already been processed
real 0m0.666s
user 0m0.605s
sys 0m0.113s
```
PR Close#29740
The `template-var-assignment` schematic currently complains if someone
assigns a value to a template variable. This will no longer work with Ivy, but
it should be totally fine to update a property of the template variable if it refers
to an object. This commit adds a test that ensures that we don't incorrectly report
any failure for such property writes in bound events.
PR Close#29708
Improves the failure messages for the `template-var-assignment` schematic. After manual
testing of the schematic it's not quite clear for developers what the failure message means
without any context. The schematic now also references a short markdown file mentioning
what needs to be changed, but eventually this document needs to be expanded with more
information and context of the reasoning behind this change within Ivy.
PR Close#29708
Previously, if a matching rootDir ended with a slash then the path
returned from `logicalPathOfFile()` would not start with a slash,
which is inconsistent.
PR Close#29627
The new styling algorithm in angular is designed to evaluate host
bindings stylinh priority in order of directive evaluation order. This,
however, does not work with respect to parent/sub-class directives
because sub-class host bindings are run after the parent host bindings
but still have priority. This patch ensures that the host styling bindings
for parent and sub-class components/directives are executed with respect
to the styling algorithm prioritization.
Jira Issue: FW-1132
PR Close#29602
Prior to this change, any provider that was independently resolved using
its InjectableDef would not be considered when destroying the module it
was requested from. This commit provides a fix for this issue by storing
the resolved provider in the module's list of provider definitions.
Fixes#28927
PR Close#28943
Paul Gschwendtner
Keen Yee Liau
Ben Lesh
Olivier Combe
Pawel Kozlowski
Andrew Kushnir
Kara Erickson
Alex Rickabaugh
Filipe Silva
Igor Minar
Kristiyan Kostadinov
Peter Johan Salomonsen
Bowen Ni
Matias Niemelä
Greg Magolan
Brandon
Frederik Prijck
Pete Bacon Darwin
Alan Agius
JoostK