By its nature, Ivy alters the import graph of a TS program, adding imports
where template dependencies exist. For example, if ComponentA uses PipeB
in its template, Ivy will insert an import of PipeB into the file in which
ComponentA is declared.
Any insertion of an import into a program has the potential to introduce a
cycle into the import graph. If for some reason the file in which PipeB is
declared imports the file in which ComponentA is declared (maybe it makes
use of a service or utility function that happens to be in the same file as
ComponentA) then this could create an import cycle. This turns out to
happen quite regularly in larger Angular codebases.
TypeScript and the Ivy runtime have no issues with such cycles. However,
other tools are not so accepting. In particular the Closure Compiler is
very anti-cycle.
To mitigate this problem, it's necessary to detect when the insertion of
an import would create a cycle. ngtsc can then use a different strategy,
known as "remote scoping", instead of directly writing a reference from
one component to another. Under remote scoping, a function
'setComponentScope' is called after the declaration of the component's
module, which does not require the addition of new imports.
FW-647 #resolve
PR Close#28169
This commit implements a cycle detector which looks at the import graph of
TypeScript programs and can determine whether the addition of an edge is
sufficient to create a cycle. As part of the implementation, module name
to source file resolution is implemented via a ModuleResolver, using TS
APIs.
PR Close#28169
Builder for `@angular/bazel` schematics should not expect bazel/ibazel
to be on the PATH. It should instead invoke the local executable
installed by yarn/npm.
PR Close#28303
Users should be able to add Bazel workspace to an existing project.
The current approach assumes that the schematics is working on the same
tree as that of ng-new, which includes the top-level directory. Instead,
the schematic should work on the tree rooted at `appRoot` to enable
Bazel files to be added to existing project.
This change uses the newly implemented ScopedTree
a0ac4b0e3d
to achieve this.
NOTE: The version of `@angular-devkit/schematics` that is installed is
used to run the `@angular/bazel` schematic. Even if a different version
is used in the schematic itself, it has no effect.
Therefore, the *latest* Angular CLI should be used to generate the
files. As of this commit, the latest version is @angular/cli@7.3.0-rc.0
PR Close#28349
TestBed.compileComponents has always been an async API. However,
ViewEngine tolerated using this API in a synchronous manner if the
components declared in the testing module did not have any async
resources (templateUrl, styleUrls). This change makes the ivy TestBed
mirror this tolerance by configuring such components synchronously.
Ref: FW-992
PR Close#28350
ngcc's reflection host needs to be able to determine all members of a
class, which it does by using the `ts.Symbol` from TypeScript's
TypeChecker. Such Symbol however may represent multiple class members
in the case of accessors; an equally named getter/setter accessor pair
is combined into a single `ts.Symbol`.
This commit introduces logic to recognize such accessors in order for
both the getter and setter to be considered as class member, similar to
ngtsc's behavior when operating on original TypeScript code.
One difference wrt the TypeScript host is that ngcc cannot see to which
accessor originally had any decorators applied to them, as decorators
are applied to the property descriptor in general, not a specific accessor.
If an accessor has both a setter and getter, any decorators are only
attached to the setter member.
PR Close#28357
Prior to this change, accessor functions for getters and setters would
not be considered as class member, as their declaration is vastly
different from ES2015 syntax.
With this change, the ES5 reflection host has learned to recognize the
downleveled syntax for accessors, allowing for them to be considered as
class member once again.
Fixes#28226
PR Close#28357
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
This commit unifies handling of the "check no changes" mode between
ngIvy and the view engine. More specifically:
- check no changes can be invoked before change detection in ivy;
- `undefined` values are considered equal `NO_CHANGES` for the "check no changes"
mode purposes.
Chanes in this commit enables several tests that were previously running only in ivy
or only in the view engine.
PR Close#28366
Prior to this change the postprocess step relied on the order of placeholders combined in one group (e.g. [�#1�|�*1:1�]). The order is not guaranteed in case we have nested templates (since we use BFS to process templates) and some tags are represented using same placeholders. This change performs postprocessing more accurate by keeping track of currently active template and searching for matching placeholder.
PR Close#28209
Due to the fast moving nature of the Ivy codebase, the timing isn't
right to make changes to how errors and reported and handled during the
runtime.
Once ivy is stable this test should be revisted because that stage there
will be a better and more robust understanding of how ivy should recover
from runtime errors.
Jira Issue: FW-952
PR Close#28212
This ensures that the SW is cleaned up, even in cases where
synchronization is disabled (and thus the clean-up inside `goTo()`
happens without waiting for Angular).
PR Close#28290
For asynchronous callbacks, this can be done either by calling
`done.fail()` or by returning the promise directly (without requesting a
`done` callback). (Using the latter, because it is shorter.)
PR Close#28290
DebugElement.properties should contain a map of element
property names to element property values, with entries
for both normal property bindings and host bindings.
This commit adds support for property bindings in
DebugElement.properties (including interpolations).
PR Close#28355
DebugElement.properties should contain a map of element
property names to element property values, with entries
for both normal property bindings and host bindings.
Many Angular core tests depend on this map being present.
This commit adds support for host property bindings in
DebugElement.properties, which fixes the Angular core tests.
There is still work to be done for normal property bindings.
PR Close#28355
The value here is unimportant on initialization since it's not looked at until the second navigation. However, sometimes in testing the `Location` service is mocked out, or the Router constructor manually called. Assuming `Location` exists in the constructor leads to test failures in `google3` therefore we initialize to a value that will not cause errors.
PR Close#28376
Show top menu at 992px screen width. The JS expression was checking just for screen widths
strictly greater than 992px to show the menu, while the CSS media query was showing the hamburger
icon just for screen widths strictly smaller than 992px, so there was a gap of 1px that the user
could't navigate through the top menu.
closes#24324
PR Close#26418
The `.properties-table` selector does not match any element and the
styles don't look relevant for the similarly named `.property-table`
class.
PR Close#28104
animate functions now contain style functions instead of plain objects
e.g. animate(1s, { background: black }))
to animate(1s, style({ background: black }))
PR Close#28305
Previous to this change, we were storing view queries at the
wrong index. This is because we were passing a raw index to the
store() instruction instead of an adjusted index (i.e. an
index that does not include the HEADER_OFFSET). We had an
additional issue where TView.blueprint was not backfilled
when TView.data was backfilled, so new component instances
created from the blueprint would end up having a shorter LView.
Both of these problems together led to the Material demo app
failing with Ivy. This commit fixes those discrepancies.
PR Close#28327
Previously, bootstrapping a component with render3 would create a chained injector with the test bed ngModule instead of the ngModule that the component belongs to.
Now when a component belongs to an ngModule, we use that for the chained injector, ensuring the correct injection of any providers that this ngModule contains.
FW-776 #resolve
PR Close#28183
Fixes components with native content projection (using `<content>` or `<slot>`) not working under Ivy.
The issue comes from the fact that when creating elements inside a component, we sometimes don't append the element immediately, but we leave it to projection to move it into its final destination. This ends up breaking the native projection, because the slots have to be in place from the beginning. The following changes switch to appending the element immediately when inside a component with Shadow DOM encapsulation.
This PR resolves FW-841.
PR Close#28261
There are cases where we should check an element injector but don't go
into the associated module injector if a token is not found. In both the
view engine and ngIvy this is acheived by passing the
`NOT_FOUND_CHECK_ONLY_ELEMENT_INJECTOR` as the `notFoundValue`.
Before this fix the view engine and ngIvy were using different objects to
represent `NOT_FOUND_CHECK_ONLY_ELEMENT_INJECTOR`. This was causing problems
as ngUpgrade is using `NOT_FOUND_CHECK_ONLY_ELEMENT_INJECTOR` const in its
`NgAdapterInjector` to prevent searching of module injectors.
This commit makes sure that ngIvy is using the same object to represent
`NOT_FOUND_CHECK_ONLY_ELEMENT_INJECTOR` as the view engine.
PR Close#28313
George Kalpakas
Alex Rickabaugh
Keen Yee Liau
Pawel Kozlowski
Jeremy Elbourn
JoostK
Paul Gschwendtner
Keen Yee Liau
WilliamKoza
Greg Magolan
Marc Laval
Miško Hevery
Martin Sikora
Andrew Kushnir
Matias Niemelä
Kara Erickson
Jason Aden
Carlos Schneider
Dario Braun
Felix Lemke
Daniel Ruf
Olivier Combe
Kristiyan Kostadinov