The type-check block generated with `"fullTemplateTypeCheck"` was
invalid if the it contained a template ref as would be generated
using the `else` micro-syntax of `NgIf`.
Fixes: #19485
PR Close#20463
- update to TypeScript 2.5
- point the 2.4 typings test at the previous typescript version, so we
don't break it accidentally
- widen the peerDeps from Angular packages that depend on TypeScript
- update to latest TypeScript 2.5 compatible Bazel rules
- move .bazelrc to tools/bazel.rc per https://docs.bazel.build/versions/master/best-practices.html#bazelrc
PR Close#20175
Throwing an exception in a lifecycle event will delay but not
prevent an Init method, such as `ngOnInit`, `ngAfterContentInit`,
or `ngAfterViewInit`, from being called. Also, calling `detectChanges()`
in a way that causes duplicate change detection (such as a
child component causing a parent to call `detectChanges()` on its
own `ChangeDetectorRef`, will no longer prevent change `ngOnInit`,
`ngAfterContentInit` and `ngAfterViewInit` from being called.
With this change lifecycle methods are still not guarenteed to be
called but the Init methods will be called if at least one change
detection pass on its view is completed.
Fixes: #17035
PR Close#20258
This commit fixes the options passed to ReflectorHost to include 'paths'
if it's specified in compiler options, so that dependency modules can
be loaded.
PR Close#20222
`cmp:host {}` and `cmp:host some-other-selector {}` were not handled
consistently.
Note those should not match anything but are made equivalent to respectively
`:host(cmp)` and `:host(cmp) some-other-selector` to avoid breaking legacy apps.
This allows to overwrite templates for JIT and AOT components alike.
In contrast to `TestBed.overrideTemplate`, the template is compiled
in the context of the testing module, allowing to use other testing
directives.
Closes#19815
This PR was merged without API docs and general rollout plan.
We can't release this as is in 5.1 without a plan for documentation, cli integration, etc.
It's illegal to coerce a Symbol to a string, and results in a TypeError:
TypeError: Cannot convert a Symbol value to a string
Previously, the custom jasmineToString() method monkey-patched onto Maps
in platform-browser/testing/src/matchers.ts would coerce keys and values
to strings. A change in a newer version of Jasmine calls this method more
often, resulting in calls against Maps which contain Symbols in some
applications, which causes crashes.
The fix is to explicitly convert keys and values to strings, which does
work on Symbols.