If tests are bundled using e.g. esbuild, the `ee` symbols may
be rewritten to `\u0275\u0275`. This breaks assertions that
rely on `Function.toString`. We can avoid this string comparison
and make it more future proof by just comparing the symbols directly.
PR Close#48521
Since we generate a `.mjs` file as entry-point for jasmine tests,
a couple of issues prevented the transitive dependencies from
bootstrap targets to be brought in (causing resolution errors):
1. The `_files` (previously `_esm2015`) targets are no longer needed,
and they also miss all the information on runfiles.
2. The aspect for computing linker mappings does not respect the
`bootstrap` attribute from the `spec_entrypoint` so we manually
add the extract ESM output targets (this rule works with the aspect
and forwards linker mappings).
PR Close#48521
For every `ts_library` target we expose a shorthand that grants
access to the JS files because `DefaultInfo` of a ts library
only exposes the `.d.ts` files.
We rename this away from `es2015` since in practice it's a much
higher target these days. Additionally we no longer use the devmode
output but rather use the prodmode output which has the explicit
`.mjs` output- compatible with ESM.
PR Close#48521
This commit removes several debug data structures from
the framework runtime. The data structures in question
were introduced in the framework in the past with the
idea of having debugging aid in the form of the human-redable
data structures. It turned out that in practice those
data structures were not used (most of the fwk developers
didn't even know about their existence!), yet we kept
paying the price of maintaining those duplicated (prod
and debug) version of the data structures.
PR Close#48281
`TNode`s have the `directiveStart` and `directiveEnd` properties that indicate the indexes at which directive instances (including components) have been stored. Currently there are several places throughout the codebase which assume that if a component matches a node, its index will always be `directiveStart`.
As far as I can tell, we probably ended up accumulating these assumptions, because we needed a quick way of accessing the component instance and it happened to be conventiently stored at `directiveStart`. The reason why it's always stored at `directiveStart` is likely to match the lifecycle hook execution order from ViewEngine.
With host directives these assumptions won't be valid anymore, because we want the host directives to _always_ execute before the host component that they're on so that the host has a chance to override them. To achieve this we have to insert host directives before the component.
These changes address the issue by introducing a new `TNode.componentOffset` property which indicates the offset after `TNode.directiveStart` at which the component is stored. Furthermore, I've removed the `isComponentHost` flag since it was duplicating the information from `TNode.componentOffset` and I've audited and fixed all the places where we read `directiveStart` to account for the changed data structure.
Reasons for some of the decisions I made along the way:
* In the case of host directives, I decided to go against our current convention of executing the component lifecycle hooks before the directive, because lifeycle hooks are a chance to change the component state (e.g. in `ngOnChanges`) and running the component hooks first would allow the host directives to undo any overrides made by the host.
* I decided to go with a `componentOffset`, instead of a `componentIndex` indicating the exact index the component is at, because as the runtime is set up at the moment, it would be difficult to know what index the component is going to end up at. Another problem is that we appear to have some logic that moves the entire "directive window" by incrementing both `directiveStart` and `directiveEnd`. By using an offset, we don't have to worry about the index remaining correct.
PR Close#47490
Adds support for TypeScript 4.8 and resolves some issues that came up as a result of the update.
Most of the issues came from some changes in TypeScript where the `decorators` and `modifiers` properties were removed from most node types, and were combined into a single `modifiers` array. Since we need to continue supporting TS 4.6 and 4.7 until v15, I ended up creating a new `ngtsc/ts_compatibility` directory to make it easier to reuse the new backwards-compatible code.
PR Close#47038
The `RootContext` implementation contained a number of fields that were needed to support an experimental `renderComponent` function. The `renderComponent` function was removed, which allows us to cleanup the `RootContext` further.
The only field that remains on the `RootContext` is the list of bootstrapped components. This list is presumably mostly unused right now (it just contains the current component) and further refactoring can happen in a followup PR.
PR Close#46806
Karma jasmine updated the `jasmine-core` dependency. Jasmine is now more
strict when:
* The done callback is invoked multiple times
* The done callback is used, while a promise is also returned
* The done callback is treated as error when e.g. a number is returned
as first argument. This was the case with `requestAnimationFrame`.
This commit refactors the code to move some functions around to avoid circular dependencies in TS imports. The newly added functions are now located in the `packages/core/src/render3/component.ts` file (instead of `packages/core/src/render3/component_ref.ts`), which is a better place for them anyway.
PR Close#46685
This change adds the setInput method to the ComponentRef.
Previously users had to call `componentRef.instance['inputName']`
to change inputs of a dynamically created component. This had
several problems:
* OnPush components were not marked for check and thus very
difficult to test;
* input aliasing was not take into account - a property name
on a component could have been different from the actual input
name so setting input properties was fragile;
* manually setting input propertie would NOT trigger the
`NgOnChanges` lifecycle hook.
This modifications unifies `@Input` accross dynamically created
components and the ones referenced in templates. This also opens
doors to other changes: as an example router could use this new
method to set `@Input`s from router params.
Closes#12313Closes#22567
PR Close#46641
This commit migrates any remaining Angular tests which are using some form
of Renderer3 interfaces. Instead, they're switched to Renderer2.
PR Close#46605
Due to the restrictions of circular dependency checking, we need a separate
internal interface for a renderer. We cannot use `Renderer2` as a type
internally as even importing it as a type incurs a dependency on its
implementation, which creates a major potential for circular dependencies.
Previously this role was served by the `Renderer3` type. As we prepare to
remove the `Renderer3` abstraction (the idea of using `document` as a
differently-shaped renderer), this commit renames `ProceduralRenderer3` to
the more generic term `Renderer`.
`RendererFactory3` is also renamed to the more generic `RendererFactory` for
consistency.
PR Close#46605
Remove calls to enableRenderer3 in the functional unit tests.
This effectivelly cuts code paths going through the Renderer3
in the functional tests.
PR Close#46612
This commit updates various tests to use TestBed instead of hand-written instructions, which makes tests easier to maintain and allows to perform further cleanup.
PR Close#46561
The `Renderer3` abstraction in Angular was an experimental code path in Ivy
which uses direct DOM operations instead of the former `Renderer2` path. To
allow `Renderer2` to tree-shake away, `Renderer3` is the default _unless_
`Renderer2` is provided. It was only an experiment, and never meant to be a
production code path.
However, it's possible for `Renderer3` to leak into user code. This commit
prevents that possibility by causing the `Renderer3` path to throw, unless
an explicit function has been called to enable it.
PR Close#46530
This commit updates a set of tests to avoid using hand-written instructions and replace them with TestBed APIs. Some tests were moved to the `acceptance` folder to colocate them with other renderer-related tests.
PR Close#46525
di_spec.ts was using handwritten definitions and the `renderComponent`-based
`ComponentFixture` (left over technical debt from the early days of Ivy.
This commit updates it to:
* remove unnecessary tests ("limp mode" DI, Renderer3, etc)
* convert other tests to use JIT-compiled classes and not handwritten defs
PR Close#46522
This commit finishes converting providers_spec.ts from `ComponentFixture`
and handwritten definitions to TestBed and JIT-compiled standalone
components.
PR Close#46527
This commit replaces usage of the internal `directiveInject` instruction
with the public `inject` function, as part of a larger cleanup of
providers_spec.ts.
PR Close#46527
This commit convers the providers_helper utility function
`expectProvidersScenario` to use the TestBed internally instead of
`ComponentFixture` and handwritten defs. This required several adjustments:
* Making the `ngModule`s passed in to the helper utility real NgModules.
* Using `ViewEncapsulation.None` for the test components (stabilizes the
generated HTML).
* Convert handwritten test components & directives into JIT-compiled
standalone equivalents.
PR Close#46527
We've had a TODO to expose ManualOnPush for a long time, but it hasn't moved since then. These changes remove it since it would be easy to re-introduce if we wanted to, it frees up an extra space in the flags bitmap and it removes some `render3` tests that we won't have to migrate to `TestBed`.
PR Close#45943
The NodeJS Bazel linker does not work well on Windows because there
is no sandboxing and linker processes from different tests will attempt
to modify the same `node_modules`, causing concurrency race conditions
and resulting in flakiness.
PR Close#45872
Adds support for TypeScript 4.7. Changes include:
* Bumping the TS version as well as some Bazel dependencies to include https://github.com/bazelbuild/rules_nodejs/pull/3420.
* Adding a backwards-compatibility layer for calls to `updateTypeParameterDeclaration`.
* Making `LView` generic in order to make it easier to type the context based on the usage. Currently the context can be 4 different types which coupled with stricter type checking would required a lot of extra casting all over `core`.
* Fixing a bunch of miscellaneous type errors.
* Removing assertions of `ReferenceEntry.isDefinition` in a few of the language service tests. The field isn't returned by TS anymore and we weren't using it for anything.
* Resolving in error in the language service that was caused by TS attempting to parse HTML files when we try to open them. Previous TS was silently setting them as `ScriptKind.Unknown` and ignoring the errors, but now it throws. I've worked around it by setting them as `ScriptKind.JSX`.
PR Close#45749
This commit reorganizes the tests around the EnvironmentInjector and its use
for standalone injectors, and adds a number of new test cases.
PR Close#45687
This commit implements the `StandaloneFeature` which provides for the
creation of standalone injectors, for those components which need them. The
feature-based implementation ensures the machinery for standalone injectors
is properly tree-shakable.
PR Close#45687
This commit extracts the `importProvidersFrom` function and associated
machinery into a separate file, as opposed to being colocated with
`R3Injector`. Separating these functions will mitigate potential future
circular dependencies as `importProvidersFrom` starts being used in
different parts of the codebase.
PR Close#45687
Previously, the compiler would represent template dependencies of a
component in its component definition through separate fields (`directives`,
`pipes`).
This commit refactors the compiler/runtime interface to use a single field
(`dependencies`). The runtime component definition object still has separate
`directiveDefs` and `pipeDefs`, which are calculated from the `dependencies`
when the definition is evaluated.
This change is also reflected in partially compiled declarations. To ensure
compatibility with partially compiled code already on NPM, the linker
will still honor the old form of declaration (with separate fields).
PR Close#45672
This commit updates one of the styling tests to reset perf counters, making it order-independent and non-flaky (previously the test got random failures depending on whether there are other tests invoked before).
PR Close#45670
Updates us to version 4.0 of Jasmine and fixes some errors that were the result of us depending upon deprecated APIs. We need to do this both to stay up to date and because it was going to break eventually, because one of the Bazel packages was logging a deprecation warning that version 4.0 was required.
There were also some cases where the state of `ngDevMode` had started leaking out between tests.
PR Close#45558
Updates us to version 4.0 of Jasmine and fixes some errors that were the result of us depending upon deprecated APIs. We need to do this both to stay up to date and because it was going to break eventually, because one of the Bazel packages was logging a deprecation warning that version 4.0 was required.
There were also some cases where the state of `ngDevMode` had started leaking out between tests.
PR Close#45558
When we have an event listener inside an embedded view, we generate a `restoreView` call which saves the view inside of the LFrame. The problem is that we don't clear it until it gets overwritten which can lead to memory leaks.
These changes rework the generated code in order to generate a `resetView` call which will clear the view from the LFrame.
Fixes#42848.
PR Close#43075
