Commit Graph

54 Commits

Author SHA1 Message Date
Andrew Kushnir 942b986ef3 fix(core): properly identify modules affected by overrides in TestBed (#36649)
When module overrides (via `TestBed.overrideModule`) are present, it might affect all modules that import (even transitively) an overridden one. For all affected modules we need to recalculate their scopes for a given test run and restore original scopes at the end. Prior to this change, we were recalculating module scopes only for components that are used in a test, without taking into account module hierarchy. This commit updates Ivy TestBed logic to calculate all potentially affected modules are reset cached scopes information for them (so that scopes are recalculated as needed).

Resolves #36619.

PR Close #36649
2020-04-21 21:57:48 -04:00
Joey Perrott 698b0288be build: reformat repo to new clang@1.4.0 (#36613)
PR Close #36613
2020-04-14 12:08:36 -07:00
Andrew Kushnir 16497438d6 fix(core): run `APP_INITIALIZER`s before accessing `LOCALE_ID` token in Ivy TestBed (#36237)
Prior to this commit, Ivy TestBed was accessing locale ID before `APP_INITIALIZER` functions were called. This execution order is not consistent with the app bootstrap logic in `application_ref.ts`. This commit updates Ivy TestBed execution order to call initializers first (since they might affect `LOCALE_ID` token value) and accessing and setting locale ID after that.

Fixes #36230.

PR Close #36237
2020-03-27 11:16:57 -07:00
Andrew Kushnir 7b13977c3a fix(core): use proper configuration to compile Injectable in JIT (#35706)
Prior to this change, the logic that compiles Injectable in JIT mode used incorrect configuration that triggers a problem when `ChangeDetectorRef` is used as a dependency. This commit updates the logic to generate correct inject instruction to add the `ChangeDetectorRef` dependency in case it's requested in @Injectable class.

PR Close #35706
2020-02-27 14:01:15 -08:00
Andrew Kushnir 0a1a989fa9 perf(core): avoid recursive scope recalculation when TestBed.overrideModule is used (#35454)
Currently if TestBed detects that TestBed.overrideModule was used for module X, transitive scopes are recalculated recursively for all modules that X imports and previously calculated data (stored in cache) is ignored. This behavior was introduced in https://github.com/angular/angular/pull/33787 to fix stale transitive scopes issue (cache was not updated if module overrides are present).

The perf issue comes from a "diamond" problem, where module X is overridden which imports modules A and B, which both import module C. Under previous logic, module C gets its transitive deps recomputed multiple times, during the recompute for both A and B. For deep graphs and big common/shared modules this can be super costly.

This commit updates the logic to recalculate ransitive scopes for the overridden module, while keeping previously calculated scopes of other modules untouched.

PR Close #35454
2020-02-25 13:11:42 -08:00
Andrew Scott 4a5467bac6 fix(ivy): ensure multi providers in ModuleWithProviders are not duplicated (#34914)
The current logic pulls multiproviders up to the parent module's
provider list. The result is that the multi provider being defined both in
the imported ModuleWithProviders and the parent and getting an extra
item in the multi provided array of values. This PR fixes that problem
by not pulling providers in ModuleWithProviders up to the parent module.

PR Close #34914
2020-01-29 12:22:58 -08:00
crisbeto 5b864ede13 fix(ivy): TestBed not unwrapping imports array function when overriding provider (#34629)
Fixes an error that is thrown when a provider is overridden in `TestBed`, if the module definition of one of the imported modules uses a function for the `imports` that is set via `setNgModuleScope`. The problem was that we have a `for...of` loop that assumes that the imports are an array, but they can also be a function. This was handled correctly in other places, but this one was missed.

Note that the above-mentioned error is only thrown at runtime when the code is transpiled to es6. In es5 TS generates a call to a helper that handles the error silently so the attached unit test only fails in es6.

Fixes #34623.

PR Close #34629
2020-01-06 11:38:02 -08:00
Andrew Scott a1d0f1e5d2 fix(ivy): align TestBed.overrideProvider with what happens with providers in TestBed providers array (#33769)
In Ivy, if you do:
`TestBed.configureTestingModule({providers: [{provide: Service}]});`
the injector will attempt to inject Service as if it was simply listed
in the providers array like `{providers: [Service]}`
This fixes an inconsistency when similarly providing an override with no
`useValue` or `useFactory`.

PR Close #33769
2019-12-06 13:06:22 -08:00
Andrew Kushnir 9b6a1b85b1 refactor(ivy): check metadata presence before compiling Type in R3TestBed (#34204)
Prior to this commit, there was no check in R3TestBed to verify that metadata is resolved using a given Type. That leads to some cryptic error messages (when TestBed tries to compile a Type without having metadata) in case TestBed override functions receive unexpected Types (for example a Directive is used in `TestBed.overrideComponent` call). This commit adds the necessary checks to verify metadata presence before TestBed tries to (re)compile a Type.

PR Close #34204
2019-12-03 16:13:54 -08:00
Andrew Kushnir fd83d9479a fix(ivy): avoid using stale cache in TestBed if module overrides are defined (#33787)
NgModule compilation in JIT mode (that is also used in TestBed) caches module scopes on NgModule defs (using `transitiveCompileScopes` field). Module overrides (defined via TestBed.overrideModule) may invalidate this data by adding/removing items in `declarations` list. This commit forces TestBed to recalculate transitive scopes in case module overrides are present, so TestBed always gets the most up-to-date information.

PR Close #33787
2019-11-20 14:50:27 -08:00
Miško Hevery a681c8553a fix(ivy): shadow all DOM properties in `DebugElement.properties` (#33781)
Fixes #33695

PR Close #33781
2019-11-18 15:49:22 -08:00
Andrew Scott f1b0547f0a revert: fix(ivy): R3TestBed should clean up registered modules after each test (#32872) (#33663)
This commit reverts 475e36a.

PR Close #33663
2019-11-12 09:53:16 -08:00
Andrew Scott e1ee90c218 revert: fix(ivy): Only restore registered modules if user compiles modules with TestBed (#32944) (#33663)
This commit reverts 63256b5.

PR Close #33663
2019-11-12 09:53:16 -08:00
Andrew Kushnir eece138fa7 fix(ivy): provider override via TestBed should remove old providers from the list (#33706)
While overriding providers in Ivy TestBed (via TestBed.overrideProvider call), the old providers were retained in the list, since the override takes precedence. However, presence of providers in the list might have side-effect: if a provider has the `ngOnDestroy` lifecycle hook, this hook will be registered and invoked later (when component is destroyed). This commit updates TestBed logic to clear provider list by removing the ones which have overrides.

PR Close #33706
2019-11-11 12:46:16 -08:00
Andrew Scott 1ebe172c2e fix(ivy): Handle overrides for {providedIn: AModule} in R3TestBed (#33606)
This issue was found when debugging a test failure that was using lazy
loaded modules with the router. When doing this, the router calls
`NgModuleFactory.create` for the loaded module. This module gets a new
injector so the overrides provided in TestBed are not applied unless the
Injectable is in the providers list (which is not the case for
{providedIn...} Injectables).

PR Close #33606
2019-11-07 15:34:19 +00:00
Andrew Scott e483acaa17 fix(ivy): ensure overrides for 'multi: true' only appear once in final providers (#33104)
PR Close #33104
2019-10-28 11:00:31 -07:00
Kara Erickson cda9248b33 refactor(core): rename ngInjectorDef to ɵinj (#33151)
Injector defs are not considered public API, so the property
that contains them should be prefixed with Angular's marker
for "private" ('ɵ') to discourage apps from relying on def
APIs directly.

This commit adds the prefix and shortens the name from
ngInjectorDef to inj. This is because property names
cannot be minified by Uglify without turning on property
mangling (which most apps have turned off) and are thus
size-sensitive.

PR Close #33151
2019-10-16 16:36:19 -04:00
Kara Erickson fc93dafab1 refactor(core): rename ngModuleDef to ɵmod (#33142)
Module defs are not considered public API, so the property
that contains them should be prefixed with Angular's marker
for "private" ('ɵ') to discourage apps from relying on def
APIs directly.

This commit adds the prefix and shortens the name from
ngModuleDef to mod. This is because property names
cannot be minified by Uglify without turning on property
mangling (which most apps have turned off) and are thus
size-sensitive.

PR Close #33142
2019-10-14 23:08:10 +00:00
Kara Erickson d62eff7316 refactor(core): rename ngPipeDef to ɵpipe (#33142)
Pipe defs are not considered public API, so the property
that contains them should be prefixed with Angular's marker
for "private" ('ɵ') to discourage apps from relying on def
APIs directly.

This commit adds the prefix and shortens the name from
ngPipeDef to pipe. This is because property names
cannot be minified by Uglify without turning on property
mangling (which most apps have turned off) and are thus
size-sensitive.

PR Close #33142
2019-10-14 23:08:10 +00:00
Kara Erickson 0de2a5e408 refactor(core): rename ngFactoryDef to ɵfac (#33116)
Factory defs are not considered public API, so the property
that contains them should be prefixed with Angular's marker
for "private" ('ɵ') to discourage apps from relying on def
APIs directly.

This commit adds the prefix and shortens the name from
ngFactoryDef to fac. This is because property names
cannot be minified by Uglify without turning on property
mangling (which most apps have turned off) and are thus
size-sensitive.

Note that the other "defs" (ngPipeDef, etc) will be
prefixed and shortened in follow-up PRs, in an attempt to
limit how large and conflict-y this change is.

PR Close #33116
2019-10-14 20:27:25 +00:00
Kara Erickson 1a67d70bf8 refactor(core): rename ngDirectiveDef to ɵdir (#33110)
Directive defs are not considered public API, so the property
that contains them should be prefixed with Angular's marker
for "private" ('ɵ') to discourage apps from relying on def
APIs directly.

This commit adds the prefix and shortens the name from
ngDirectiveDef to dir. This is because property names
cannot be minified by Uglify without turning on property
mangling (which most apps have turned off) and are thus
size-sensitive.

Note that the other "defs" (ngFactoryDef, etc) will be
prefixed and shortened in follow-up PRs, in an attempt to
limit how large and conflict-y this change is.

PR Close #33110
2019-10-14 16:20:11 +00:00
Kara Erickson 64fd0d6db9 refactor(core): rename ngComponentDef to ɵcmp (#33088)
Component defs are not considered public API, so the property
that contains them should be prefixed with Angular's marker
for "private" ('ɵ') to discourage apps from relying on def
APIs directly.

This commit adds the prefix and shortens the name from
`ngComponentDef` to `cmp`. This is because property names
cannot be minified by Uglify without turning on property
mangling (which most apps have turned off) and are thus
size-sensitive.

Note that the other "defs" (ngDirectiveDef, etc) will be
prefixed and shortened in follow-up PRs, in an attempt to
limit how large and conflict-y this change is.

PR Close #33088
2019-10-11 15:45:22 -07:00
crisbeto d5b87d32b0 perf(ivy): move attributes array into component def (#32798)
Currently Ivy stores the element attributes into an array above the component def and passes it into the relevant instructions, however the problem is that upon minification the array will get a unique name which won't compress very well. These changes move the attributes array into the component def and pass in the index into the instructions instead.

Before:
```
const _c0 = ['foo', 'bar'];

SomeComp.ngComponentDef = defineComponent({
  template: function() {
    element(0, 'div', _c0);
  }
});
```

After:
```
SomeComp.ngComponentDef = defineComponent({
  consts: [['foo', 'bar']],
  template: function() {
    element(0, 'div', 0);
  }
});
```

A couple of cases that this PR doesn't handle:
* Template references are still in a separate array.
* i18n attributes are still in a separate array.

PR Close #32798
2019-10-09 13:16:55 -07:00
Andrew Scott 63256b511a fix(ivy): Only restore registered modules if user compiles modules with TestBed (#32944)
There are a couple scenarios that are problematic and need special
handling:

1. A user has a custom implementation of lazy-loaded modules, sets some
provider overrides, then compiles the module so it can be loaded. In a
follow-up test, the user sets different overrides for the module and
then compiles. This is problematic because we need to be sure the module
registered in the first test is not used, so we need to clear it out of
the modules list in `ng_module_factory_registration`.
2. A user has a similar lazy-loaded module factory implementation but
relies on the module being registered automatically. This can happen,
for example, as a side effect of importing the ngfactory file.

PR Close #32944
2019-10-01 17:17:47 -07:00
Andrew Scott 475e36abb5 fix(ivy): R3TestBed should clean up registered modules after each test (#32872)
PR Close #32872
2019-09-30 15:01:08 -07:00
Andrew Scott c8be987b40 fix(ivy): ensure TestBed restores fields to the most original value (#32823)
PR Close #32823
2019-09-25 11:28:09 -07:00
Carlos Ortiz García 9166baf709 refactor(core): Migrate TestBed.get to TestBed.inject (#32382)
This is cleanup/followup for PR #32200

PR Close #32382
2019-09-09 19:10:54 -04:00
Kristiyan Kostadinov c885178d5f refactor(ivy): move directive, component and pipe factories to ngFactoryFn (#31953)
Reworks the compiler to output the factories for directives, components and pipes under a new static field called `ngFactoryFn`, instead of the usual `factory` property in their respective defs. This should eventually allow us to inject any kind of decorated class (e.g. a pipe).

**Note:** these changes are the first part of the refactor and they don't include injectables. I decided to leave injectables for a follow-up PR, because there's some more cases we need to handle when it comes to their factories. Furthermore, directives, components and pipes make up most of the compiler output tests that need to be refactored and it'll make follow-up PRs easier to review if the tests are cleaned up now.

This is part of the larger refactor for FW-1468.

PR Close #31953
2019-08-27 13:57:00 -07:00
Andrew Kushnir d545bbeee4 fix(ivy): handle ModuleWithProviders in R3TestBed correctly (#31415)
Prior to this commit, it was impossible to override providers defined via ModuleWithProviders using TestBed.overrideProvider API. The problem was caused by the fact that we were not taking into account these providers while calculating accumulated set of provider overrides. This commit updates the logic to extract providers from ModuleWithProviders and calculate the final set of overrides taking them into account.

PR Close #31415
2019-07-11 18:27:13 -04:00
Alex Rickabaugh deb77bd3df feat(ivy): TestBed support for reusing non-exported components (#30578)
This is a new feature of the Ivy TestBed.

A common user pattern is to test one component with another. This is
commonly done by creating a `TestFixture` component which exercises the
main component under test.

This pattern is more difficult if the component under test is declared in an
NgModule but not exported. In this case, overriding the module is necessary.

In g3 (and View Engine), it's possible to use an NgSummary to override the
recompilation of a component, and depend on its AOT compiled factory. The
way this is implemented, however, specifying a summary for a module
effectively overrides much of the TestBed's other behavior. For example, the
following is legal:

```typescript
TestBed.configureTestingModule({
  declarations: [FooCmp, TestFixture],
  imports: [FooModule],
  aotSummaries: [FooModuleNgSummary],
});
```

Here, `FooCmp` is declared in both the testing module and in the imported
`FooModule`. However, because the summary is provided, `FooCmp` is not
compiled within the context of the testing module, but _is_ made available
for `TestFixture` to use, even if it wasn't originally exported from
`FooModule`.

This pattern breaks in Ivy - because summaries are a no-op, this amounts
to a true double declaration of `FooCmp` which raises an error.

Fixing this in user code is possible, but is difficult to do in an
automated or backwards compatible way. An alternative solution is
implemented in this PR.

This PR attempts to capture the user intent of the following previously
unsupported configuration:

```typescript
TestBed.configureTestingModule({
  declarations: [FooCmp, TestFixture],
  imports: [FooModule],
});
```

Note that this is the same as the configuration above in Ivy, as the
`aotSummaries` value provided has no effect.

The user intent here is interpreted as follows:

1) `FooCmp` is a pre-existing component that's being used in the test
   (via import of `FooModule`). It may or may not be exported by this
   module.

2) `FooCmp` should be part of the testing module's scope. That is, it
   should be visible to `TestFixture`. This is because it's listed in
   `declarations`.

This feature effectively makes the `TestBed` testing module special. It's
able to declare components without compiling them, if they're already
compiled (or configured to be compiled) in the imports. And crucially, the
behavior matches the first example with the summary, making Ivy backwards
compatible with View Engine for tests that use summaries.

PR Close #30578
2019-05-24 14:01:44 -04:00
Andrew Kushnir 86c46908d4 fix(ivy): R3TestBed doesn't allow template overrides with an empty string (#30602)
Prior to this change a component was considered unresolved (i.e. having dynamic resources that should be loaded, like external template or stylesheets) even if template override was provided as an empty string (for example, via TestBed.overrideTemplateUsingTestingModule call). This commit fixes the condition that previously treated empty string as an absent template value.

PR Close #30602
2019-05-22 16:25:56 -07:00
Ben Lesh d7eaae6f22 refactor(ivy): Move instructions back to ɵɵ (#30546)
There is an encoding issue with using delta `Δ`, where the browser will attempt to detect the file encoding if the character set is not explicitly declared on a `<script/>` tag, and Chrome will find the `Δ` character and decide it is window-1252 encoding, which misinterprets the `Δ` character to be some other character that is not a valid JS identifier character

So back to the frog eyes we go.

```
    __
   /ɵɵ\
  ( -- ) - I am ineffable. I am forever.
 _/    \_
/  \  /  \
==  ==  ==
```

PR Close #30546
2019-05-20 16:37:47 -07:00
Ben Lesh cf86ed7b29 refactor(ivy): migrate ɵɵ prefix back to Δ (#30362)
Now that issues are resolved with Closure compiler, we can move back to our desired prefix of `Δ`.

PR Close #30362
2019-05-14 16:52:15 -07:00
Andrew Kushnir f9bb53a761 fix(ivy): allow TestBed.createComponent to create components in isolation (#29981)
Prior to this change, components created via TestBed.createComponent in the same test were placed into the same root context, which caused problems in conjunction with fixture.autoDetectChanges usage in the same test. Specifically, change detection was triggered immediately for created component (starting from the 2nd one) even if it was not required/desired. This commit makes Ivy and VE behavior consistent: now every component created via TestBed.createComponent is isolated from each other. Current solution uses host element id naming convention, which is not ideal, but helps avoid public API surface changes at this point (we might revisit this approach later).

Note: this commit also adds extra tests to verify bootstrap and change detection behavior in case of multiple components in `bootstrap` array in @NgModule, to make sure this behavior is aligned between Ivy and VE.

PR Close #29981
2019-04-19 09:45:52 -07:00
Andrew Kushnir 5f1b6372c7 fix(ivy): multi provider override support in TestBed (#29919)
Overriding multi provider values (providers with `multi: true` flag) via TestBed require additional handling: all existing multi-provider values for the same token should be removed from the override list, so that they are not included into the final value of a given provider. This commit adds this logic to make sure we handle multi providers correctly.

PR Close #29919
2019-04-16 10:28:40 -07:00
Kara Erickson 0aa0f11a2b fix(ivy): log errors instead of re-throwing them (#29853)
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
2019-04-12 16:57:26 -07:00
Alex Rickabaugh b0578061ce refactor(ivy): use ɵɵ instead of Δ for now (#29850)
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
2019-04-11 16:27:56 -07:00
Ben Lesh 138ca5a246 refactor(ivy): prefix all generated instructions (#29692)
- Updates all instructions to be prefixed with the Greek delta symbol

PR Close #29692
2019-04-10 12:11:40 -07:00
Alex Rickabaugh 7b27009e20 fix(ivy): fix proliferation of provider overrides for modules (#29571)
When an @NgModule is imported more than once in the testing module (for
example it appears in the imports of more than one module, or if it's
literally listed multiple times), then TestBed had a bug where the
providers for the module would be overridden many times.

This alone was problematic but would not break tests. However, the original
value of the providers field of the ngInjectorDef was saved each time, and
restored in the same order. Thus, if the provider array was [X], and
overrides were applied twice, then the override array would become
[X, X'] and then [X, X', X, X']. However, on the second override the state
[X, X'] would be stored as original. The array would then be restored to
[X] and then [X, X'].

Each test, therefore, would continue to double the size of the providers
array for the module, eventually exhausting the browser's memory.

This commit adds a Set to track when overrides have been applied to a module
and refrain from applying them more than once.

PR Close #29571
2019-03-28 13:59:25 -07:00
Andrew Kushnir 71ec99856a fix(ivy): allow TestBed to recompile AOT-compiled components in case of template overrides (#29555)
Prior to this change, recompilation of AOT-compiled components in TestBed may fail when template override is requested. That was happening due to the `styleUrls` field defined for a Component, thus switching its state to "requires resolution" (i.e. having external resources) at compile time. This change avoids this issue by storing styles and resetting `styleUrls` field before recompilation. Once compilation is done, saved styles are patched back onto Component def.

PR Close #29555
2019-03-28 10:11:41 -07:00
Andrew Kushnir 309ffe7e16 fix(ivy): TestBed rewrite to avoid unnecessary recompilations (#29483)
Prior to this change, Ivy version of TestBed was not designed to support the logic to avoid recompilations - most of the Components/Directives/Pipes were recompiled for each test, even if there were no overrides defined for a given Type. Additional checks to avoid recompilation were introduced in one of the previous commits (0244a2433e), but there were still some corner cases that required attention. In order to support the necessary logic better, Ivy TestBed was rewritten/refactored. Main results of this rewrite are:

* no recompilation for Components/Directives/Pipes without overrides
* the logic to restore state between tests (isolate tests) was improved
* transitive scopes calculation no longer performs recompilation (it works with compiled defs)

As a result of these changes we see reduction in memory consumption (3.5-4x improvement) and pefromance increase (4-4.5x improvement).

PR Close #29483
2019-03-27 09:41:58 -07:00
Kristiyan Kostadinov bef5043a5a fix(ivy): TestBed overriding custom ErrorHandler (#29482)
Fixes TestBed's default ErrorHandler overriding the one provided by the consumer via an `import`.

This PR resolves FW-1193.

PR Close #29482
2019-03-22 16:45:33 -07:00
Andrew Kushnir 0244a2433e feat(ivy): avoid unnecessary recompilations in TestBed (#29294)
Prior to this change, we always recompile all Components/Directives/Pipes even if they were AOT-compiled and had no overrides. This is causing problems in case we try to recompile a Component with "templateUrl" or "styleUrls" (which were already resolved in case of AOT) and generally this unnecessary work that TestBed was doing is not required. This commit adds extra logic to check whether a Component/Directive/Pipe already have compiled NG def (like ngComponentDef) and whether there are no overrides present - in this case recompilation is skipped. Recompilation is also skipped in case a Component/Directive has only Provider overrides - in this situation providers resolver function is patched to reflect overrides. Provider overrides are very common in g3, thus this code path ensures no full recompilation.

PR Close #29294
2019-03-19 01:11:16 -04:00
Andrew Kushnir 5a2c3ff8b5 fix(ivy): proper component resolution in case of inheritance (#28439)
Ivy allows Components to extend Directives (but not the other way around) and as a result we may have Component and Directive annotations present at the same time. The logic that resolves annotations to pick the necessary one didn't take this into account and as a result Components were recognized as Directives (and vice versa) in case of inheritance. This change updates the resolution logic by picking known annotation that is the nearest one (in inheritance tree) and compares it with expected type. That should help avoid mis-classification of Components/Directives during resolution.

PR Close #28439
2019-02-05 23:29:04 -05:00
Jeremy Elbourn 3deda898d0 fix(ivy): TestBed should tolerate synchronous use of `compileComponents` (#28350)
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
2019-01-28 11:59:40 -08:00
Kara Erickson bf97d3b73e feat(ivy): support property bindings and interpolations in DebugElement (#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.

This commit adds support for property bindings in
DebugElement.properties (including interpolations).

PR Close #28355
2019-01-25 12:39:01 -08:00
Kara Erickson 46aec4a58f feat(ivy): support host properties in DebugElement.properties (#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
2019-01-25 12:39:01 -08:00
Kara Erickson 1f7d3b9a57 fix(ivy): TestBed should use annotation for the last match rather than the first (#28195)
When we look for matching annotations in TestBed, we should always take the last
matching annotation. Otherwise, we will return superclass data for subclasses,
which would have unintended consequences like directives matching the wrong selectors.

PR Close #28195
2019-01-17 09:57:30 -08:00
Andrew Kushnir a75c734471 fix(ivy): restore NG defs after running tests in TestBed (#27786)
`R3TestBed` allows consumers to configure a "testing module", declare components, override various metadata, etc. To do this, it implements its own JIT compilation, where components/directives/modules have Ivy definition fields generated based on testing metadata. It results in tests interfering with each other. One test might override something in a component that another test tries to use normally, causing failures.

In order to resolve this problem, we store current components/directives/modules defs before applying overrides and re-compiling. Once the test is complete, we restore initial defs, so the next tests interact with "clean" components.

PR Close #27786
2019-01-07 14:44:14 -08:00
Kara Erickson 062c7af4f3 test(ivy): replace resolved issue in compiler-cli test with new root cause (#27709)
PR Close #27709
2018-12-17 16:46:42 -08:00