When using ViewEncapsulation.ShadowDom, Angular will not remove the child nodes of the DOM node a root Component is bootstrapped into. This enables developers building Angular Elements to use the `<slot>` element to do native content projection.
PR Close#24861
By pulling in `compiler` into `core` the `compiler` was not
100% tree-shakable and about 8KB of code was retained
when tree-shaken with closure.
PR Close#25531
Provides a runtime and compile time switch for ivy including
`ApplicationRef.bootstrapModule`.
This is done by naming the symbols such that `ngcc` (angular
Compatibility compiler) can rename symbols in such a way that running
`ngcc` command will switch the `@angular/core` module from `legacy` to
`ivy` mode.
This is done as follows:
```
const someToken__PRE_NGCC__ = ‘legacy mode’;
const someToken__POST_NGCC__ = ‘ivy mode’;
export someSymbol = someToken__PRE_NGCC__;
```
The `ngcc` will search for any token which ends with `__PRE_NGCC__`
and replace it with `__POST_NGCC__`. This allows the `@angular/core`
package to be rewritten to ivy mode post `ngcc` execution.
PR Close#25238
When an Angular decorated class is inherited, it might be the case that
the entire inheritance chain actually has no constructor defined. In
that event, a factory which simply instantiates the type without any
arguments should be used.
PR Close#25425
When @angular/core is compiled by ngtsc, a factory file is generated
for ApplicationModule, that is currently invalid because r3_symbols
does not export NgModuleFactory. This change fixes that issue and
ensures the generated ngfactory file for @angular/core is valid.
PR Close#25392
When generating the 'directives:' property of ngComponentDef, ngtsc
needs to be conscious of declaration order. If a directive being
written into the array is declarated after the component currently
being compiled, then the entire directives array needs to be wrapped
in a closure.
This commit fixes ngtsc to pay attention to such ordering issues
within directives arrays.
PR Close#25392
This commit creates an API for factory functions which allows them
to be inherited from one another. To do so, it differentiates between
the factory function as a wrapper for a constructor and the factory
function in ngInjectableDefs which is determined by a default
provider.
The new form is:
factory: (t?) => new (t || SomeType)(inject(Dep1), inject(Dep2))
The 't' parameter allows for constructor inheritance. A subclass with
no declared constructor inherits its constructor from the superclass.
With the 't' parameter, a subclass can call the superclass' factory
function and use it to create an instance of the subclass.
For @Injectables with configured providers, the factory function is
of the form:
factory: (t?) => t ? constructorInject(t) : provider();
where constructorInject(t) creates an instance of 't' using the
naturally declared constructor of the type, and where provider()
creates an instance of the base type using the special declared
provider on @Injectable.
PR Close#25392
data about tasks.
When building a list of pending tasks for callers of whenStable(),
Testability will copy data about the task into a new object, in order to
avoid leaking references to tasks.
This change copies more properties from Tasks into the list of pending
tasks, as well as a reference to Task.data to give callers more
information about the tasks that are pending.
Specifically, this also copies runCount and task ID, which are needed in
order for callers to know when a given task is repeating.
PR Close#25010
To match the View Engine behavior.
We should make this configurable so that the node injector is tree shaken when
directives do not need to be published.
PR Close#25291
This commit adds basic support for <ng-container> - most of the
functionality should work as long as <ng-container> is a child of
a regular element.
PR Close#25227
Before the `ngDevMode` had to be set explicitly or it would throw
an exception at runtime. This changes it so that if `ngDevModu` is
`undefined` than we default to `ngDevMode = true`. In other words
unless the developer has explicitly asked to make a prodution build
by setting `ngDevMode = false` as compilation constant, the default
is `ngDevMode = true`.
This also fixes a minor bug where the setup code would read
`global['ngDevMode']` but all other code would read `global.ngDevMode`.
This would cause issues with closure compiler since the
reading of the `ngDevMode` must be consistent.
PR Close#25208
Update XMB placeholders(<ph>) to include the original value on top of an
example. Placeholders can by definition have one example(<ex>) tag and a
text node. The text node is used by TC as the "original" value from the
placeholder, while the example should represent a dummy value.
For example: <ph name="PET"><ex>Gopher</ex>{{ petName }}</ph>.
This change makes sure that we have the original text, but it *DOES NOT*
make sure that the example is correct. The example has the same wrong
behavior of showing the interpolation text rather than a useful
example.
No breaking changes, but tools that depend on the previous behavior and
don't consider the full XMB definition may fail to parse the XMB.
Fixes b/72565847
PR Close#25079
- `directiveInjector()` is used to inject anything in the directive / component
/ pipe factories so adding `InjectionToken<T>` as a supported token type.
- `getOrCreateInjectable()` should search first in the node injector tree and
then in the module injector tree (was either or before the PR).
PR Close#25166
When ngtsc encounters a reference to a type (for example, a Component
type listed in an NgModule declarations array), it traces the import
of that type and attempts to determine the best way to refer to it.
In the event the type is defined in the same file where a reference
is being generated, the identifier of the type is used. If the type
was imported, ngtsc has a choice. It can use the identifier from the
original import, or it can write a new import to the module where the
type came from.
ngtsc has a bug currently when it elects to rely on the user's import.
When writing a .d.ts file, the user's import may have been elided as
the type was not referred to from the type side of the program. Thus,
in .d.ts files ngtsc must always assume the import may not exist, and
generate a new one.
In .js output the import is guaranteed to still exist, so it's
preferable for ngtsc to continue using the existing import if one is
available.
This commit changes how @angular/compiler writes type definitions, and
allows it to use a different expression to write a type definition than
is used to write the value. This allows ngtsc to specify that types in
type definitions should always be imported. A corresponding change to
the staticallyResolve() Reference system allows the choice of which
type of import to use when generating an Expression from a Reference.
PR Close#25080
Rob Wormald
Miško Hevery
Pawel Kozlowski
Kara Erickson
Matias Niemelä
Alan Agius
George Kalpakas
Alex Eagle
Ben Lesh
Greg Magolan
Victor Berchet
Kieran Whiteman
Alex Rickabaugh
Igor Minar
JiaLi.Passion
Roope Hakulinen
Michael Giambalvo
vincecampanale
Vani
Jessy Cormier
JoostK
Aldo Roman Nureña
Aldo Roman
mhartington
Marc Laval
Carlos Ortiz Garcia
Olivier Combe