These docs were linking directly to docs that have ambiguous paths.
These changes ensure that these links are not affected by the
disambiguation processing of those docs.
PR Close#41788
Currently we save a reference to an `LView` on most DOM nodes created by Angular either by saving
the `LView` directly in the `__ngContext__` or by saving the `LContext` which has a reference to
the `LView`. This can be a problem if the DOM node is retained in memory, because the `LView` has
references to all of the child nodes of the view, as well as other internal data structures.
Previously we tried to resolve the issue by clearing the `__ngContext__` when a node is removed
(see https://github.com/angular/angular/pull/36011), but we decided not to proceeed, because it can
slow down destruction due to a megamorphic write.
These changes aim to address the issue while reducing the performance impact by assigning a unique
ID when an `LView` is created and adding it to `__ngContext__`. All active views are tracked in
a map where their unique ID is used as the key. We don't need to worry about leaks within that map,
because `LView`s are an internal data structure and we have complete control over when they are
created and destroyed.
Fixes#41047.
PR Close#41358
`global` property is not available in the browser, previously this was polyfilled through `core-js`. This now fails with `global is not defined`, since global cannot be accessed when not defined.
PR Close#41739
`global` property is not available in the browser, previously this was polyfilled through core-js.
(cherry picked from commit 827cf41386dcd7e496e107d6b32c54281bc935f1)
PR Close#41739
`core-js` is a CJS package which cannot be used directly in the browser. `core-js-bundle` is the bundled version of the package which can be used in directly in the browser.
PR Close#41739
Currently we have a lot of places where we repeat the type `Type<T>|AbstractType<T>|InjectionToken<T>` which makes it cumbersome to add another type or to type something else with the same signature.
These changes add a new type that can be used instead.
Fixes#39792.
PR Close#41580
This commit refactors the code to replace `loadLContext` with `getLContext` calls. The only difference between these two functions is that the `loadLContext` supports throwing an error in case `LContext` can not be found. The investigation performed in #41525 revealed that throwing while retrieving `LContext` might have undesirable performance implications, so we should avoid that to make sure there are no accidental perf regressions in other parts of code that used `loadLContext`. Moreover, in most of the places the `loadLContext` was already called in a mode that prevented an error from being thrown, so this refactoring should have no effect on the actual behavior.
PR Close#41606
Some partial libraries have been minified, which results in the declaration
calls being being converted from property accesses to indexed accesses.
This commit ensures that the linker can process these calls.
Fixes#41655
PR Close#41747
Some partial libraries have been minified, which results in boolean literals
being converted to `!0` and `!1`. This commit ensures that the linker can
process these values.
Fixes#41655
PR Close#41747
Close#41520.
This case related to the issue #41522.
```
Zone.root
.fork({
name: 'xhr',
onHasTask(delegate, currentZone, zone, taskState) {
console.log('hasMacrotask', taskState.macroTask);
return delegate.hasTask(zone, taskState);
},
})
.run(() => {
const xhr = new XMLHttpRequest();
xhr.open('GET', 'https://cdnjs.cloudflare.com/ajax/libs/zone.js/0.11.4/zone.min.js');
xhr.addEventListener('load', () => {
throw new Error();
});
xhr.send();
});
```
zone.js invoke all `onload` event handlers before change the XHR task's state from
`scheduled` to `notscheduled`, so if any `onload` listener throw error, the XHR task
wlll be hang to `scheduled`, and leave the macroTask status in the zone wrongly.
This has been fixed in the previous commit, this commit add test to verify the case.
PR Close#41562
Close#41522
`zone.js` patches event listeners and run all event listeners together, if
one event handler throws error, the listeners afterward may not be invoked.
Reproduction:
```
export class AppComponent implements AfterViewInit {
@ViewChild('btn') btn: ElementRef;
title = 'event-error';
constructor(private ngZone: NgZone) {}
ngAfterViewInit() {
this.ngZone.runOutsideAngular(() => {
this.btn.nativeElement.addEventListener('click', () => {
throw new Error('test1');
});
this.btn.nativeElement.addEventListener('click', () => {
console.log('add eventlistener click');
});
});
}
}
```
Until now no Angular users report this issue becuase in the `ngZone`, all
error will be caught and will not rethrow, so the event listeners afterward
will still continue to execute, but if the event handlers are outside of `ngZone`,
the error will break the execution.
This commit catch all errors, and after all event listeners finished invocation,
rethrow the errors in seperate `microTasks`, the reason I am using `microTask` here
is to handle multiple errors case.
PR Close#41562
We have a check that determines whether to generate property binding instructions for an `ng-template`. The check looks at whether the tag name is exactly `ng-template`, but the problem is that if the tag is placed in a non-HTML namespace (e.g. `svg`), the tag name will actually be `:namespace:ng-template` and the check will fail.
These changes resolve the issue by looking at the tag name without the namespace.
Fixes#41308.
PR Close#41669
documentation of decendants property of @ContentChildren was not clear when decendants was set to false it did not pick up direct children when any directive was used on the elements. With Ivy the functionality follows the following pattern only query direct children (in the sense of elements in a template) when descendants: false is specified.
Fixes#20074
PR Close#35927
Close#41520.
This case related to the issue #41522.
```
Zone.root
.fork({
name: 'xhr',
onHasTask(delegate, currentZone, zone, taskState) {
console.log('hasMacrotask', taskState.macroTask);
return delegate.hasTask(zone, taskState);
},
})
.run(() => {
const xhr = new XMLHttpRequest();
xhr.open('GET', 'https://cdnjs.cloudflare.com/ajax/libs/zone.js/0.11.4/zone.min.js');
xhr.addEventListener('load', () => {
throw new Error();
});
xhr.send();
});
```
zone.js invoke all `onload` event handlers before change the XHR task's state from
`scheduled` to `notscheduled`, so if any `onload` listener throw error, the XHR task
wlll be hang to `scheduled`, and leave the macroTask status in the zone wrongly.
This has been fixed in the previous commit, this commit add test to verify the case.
PR Close#41562
Close#41522
`zone.js` patches event listeners and run all event listeners together, if
one event handler throws error, the listeners afterward may not be invoked.
Reproduction:
```
export class AppComponent implements AfterViewInit {
@ViewChild('btn') btn: ElementRef;
title = 'event-error';
constructor(private ngZone: NgZone) {}
ngAfterViewInit() {
this.ngZone.runOutsideAngular(() => {
this.btn.nativeElement.addEventListener('click', () => {
throw new Error('test1');
});
this.btn.nativeElement.addEventListener('click', () => {
console.log('add eventlistener click');
});
});
}
}
```
Until now no Angular users report this issue becuase in the `ngZone`, all
error will be caught and will not rethrow, so the event listeners afterward
will still continue to execute, but if the event handlers are outside of `ngZone`,
the error will break the execution.
This commit catch all errors, and after all event listeners finished invocation,
rethrow the errors in seperate `microTasks`, the reason I am using `microTask` here
is to handle multiple errors case.
PR Close#41562
Currently if a component defines a template inline, but not through a
string literal, the partial compilation references the template expression
as is. This is problematic because the component declaration can no longer
be processed by the linker later as there is no static interpretation. e.g.
```js
const myTemplate = `...`;
TestCmp.ɵcmp = i0.ɵɵngDeclareComponent({
version: "0.0.0-PLACEHOLDER",
type: TestCmp,
selector: "test-cmp",
ngImport: i0,
template: myTemplate,
isInline: true
});
```
To fix this, we use the the resolved template in such cases so that
the linker can process the template/component declaration as expected.
PR Close#41583
With the introduction of the partial compilation, the Angular compiler's
existing `parseTemplate` method has been extended to pass through multiple
properties purely in favor of the partial compilation.
e.g. the `parseTemplate` function now accepts an "option" called `isInline`.
This option is just passed through and returned as part of the `ParsedTemplate`.
This is not ideal because the `parseTemplate` function doesn't care
whether the specified template was inline or not. This commit cleans
up the `parseTemplate` compiler function so that nothing needed only
for the partial compilation is added to it.
We introduce a new struct for additional template information that
is specific to the generation of the `declareComponent` function. With
that change, we can simplify the component decorator handler and keep
logic more local.
PR Close#41583
This adds string literals, number literals, `true`, `false`, `null` and
`undefined` to autocomplete results in templates.
For example, when completing an input of union type.
Component: `@Input('input') input!: 'a'|'b'|null;`
Template: `[input]="|"`
Provide `'a'`, `'b'`, and `null` as autocompletion entries.
Previously we did not include literal types because we only included
results from the component context (`ctx.`) and the template scope.
This is the second attempt at this. The first attempt is in
1d12c50f63 and it was reverted in 75f881e078150b0d095f2c54a916fc67a10444f6.
PR Close#41645
The `ViewportScroller` figures out which element to scroll into view using `document.getElementById`. The problem is that it won't find elements inside the shadow DOM.
These changes add some extra logic that goes through all the shadow roots to look for the element.
Fixes#41470.
PR Close#41644
When determining whether to run an animation, the `TransitionAnimationPlayer`
checks to see if a DOM element is attached to the document. This is done by
checking to see if the element is "contained" by the document body node.
Previously, if the element was inside a shadow DOM, the engine would
determine that the element was not attached, even if the shadow DOM's
host was attached to the document. This commit updates the `containsElement()`
method on `AnimationDriver` implementations to also include shadow DOM
elements as being contained if their shadow host element is contained.
Further, when using CSS keyframes to trigger animations, the styling
was always added to the `head` element of the document, even for
animations on elements within a shadow DOM. This meant that those
elements never receive those styles and the animation would not run.
This commit updates the insertion of these styles so that they are added,
to the element's "root node", which is the nearest shadow DOM host, or the
`head` of the document if the element is not in a shadow DOM.
Closes#25672
PR Close#40134
When creating the router state, the `RouteReuseStrategy#retrieve` should
only be called when `RouteReuseStrategy#shouldAttach` returns `true`.
That is, we should only retrieve a stored route when the reuse strategy
indicates that there is one stored and that it should be reattached.
This now matches the behavior in the route activation:
1d12c50f63/packages/router/src/operators/activate_routes.ts (L170-L172)Fixes#23162
PR Close#30263
This situation can probably happen only when using
`HashLocationStrategy` and by manually changing hash that triggers a route
guard that returns a new `UrlTree`. Then hash in the browser might not
match the current route because navigation was canceled, while hash in
the URL remained set by the user.
Related to #37048
PR Close#40409
This is follow-up from #41437 and it reduces the amount of code we generate for safe property accesses (`a?.b`) and nullish coalescing (`a ?? b`) by:
1. Reusing variables in nested nullish coalescing expressions.
2. Not initializing temporary variables to `null`. The way our code is generated means that the value will always be overwritten before we compare against it so the initializer didn't really matter.
Fixes#41491.
PR Close#41563
When recognizing routes, the router merges nodes which map to the same
empty path config. This is because auxiliary outlets under empty path
parents need to match the parent config. This would result in two
outlet matches for that parent which need to be combined into a single
node: The regular 'primary' match and the match for the auxiliary outlet.
In addition, the children of the merged nodes should also be merged to
account for multiple levels of empty path parents.
Fixes#41481
PR Close#41584
The asynchronous preprocessing check was not accounting for components that did not have any inline styles. In that case, the cache did not have an entry which then allowed the asynchronous check to run and fail the compilation. The caching during the asynchronous analysis phase now handles components without inline styles.
PR Close#41602
Previously, it was not possible to block a partial-linker from trying to
process a declaration that was defined in a newer version of Angular than
that of the partial-linker. For example, if a partial-linker was published as
part of version 12.0.0, there was no way for a partially-compiled declaration
compiled via version 13.0.0 to tell the 12.0.0 linker that it would be invalid
to attempt to process it.
This commit adds a new `minVersion` property to partial-declarations, which is
interpreted as the "minimum partial-linker version" that can process this
declaration. When selecting a partial-linker for such a declaration, the known
linker version ranges are checked to find the most recent linker whose version
range has an overlap with the interpreted declaration range.
This approach allows us to set a minimum version for a declaration, which
can inform an old partial-linker that will it not be able to accurately
process the declaration.
Note that any pre-release part to versions are ignored in this selection
process.
The file-linker can be configured, via the `unknownDeclarationVersionHandling`
property of `LinkerOptions`, to handle such a situation in one of three ways:
- `error` - the version mismatch is a fatal error
- `warn` - a warning is sent to the logger but the most recent partial-linker
will attempt to process the declaration anyway.
- `ignore` - the most recent partial-linker will, silently, attempt to process
the declaration.
The default is to throw an error.
Closes#41497
PR Close#41578
In version 12, applications will only be allowed to be built in Ivy, this makes the minified UMDs redundant since they cannot be processed by NGCC.
With this change, we remove the minified UMDs from the generated APF package.
BREAKING CHANGE: Minified UMD bundles are no longer included in the distributed NPM packages.
PR Close#41425
Update the supported range of node versions for Angular. Angular now
supports node >=12.14.1 to <16.0.0, dropping support for Node v10.
BREAKING CHANGE: Angular no longer maintains support for node v10
PR Close#41544
With this commit, the language service will first try to locate a
pre-compiled style file with the same name when a `css` is provided in
the `styleUrls`. This prevents a missing resource diagnostic for when the
compiled file is not available in the language service environment and also
allows "go to definition" to go to that pre-compiled file.
Fixes angular/vscode-ng-language-service#1263
PR Close#41538
The language service uses an elements attributes to determine if it
matches a directive in the component scope. We do this by accumulating
all attribute bindings and matching against the selectors for the
available directives. The compiler itself does a similar thing. In
addition, the compiler does not use the value of `BoundAttribute`s to
match directives (cdf1ea1951/packages/compiler/src/render3/view/util.ts (L174-L206)). This commit changes the language
service to also ignore bound attribute values for directive matching.
Fixes https://github.com/angular/vscode-ng-language-service/issues/1278
PR Close#41597
Updates to the latest version of `rules_nodejs` that supports
the most recent NodeJS lts version v14.16.1.
Additionally the latest version of `rules_nodejs` provides
[a package for runfile resolution](https://github.com/bazelbuild/rules_nodejs/pull/2568) w/ types that we can leverage.
PR Close#41599
This commit introduces the following optimizations:
1. We return an empty array for text nodes in `getDirectives` because
Angular does not support attaching logic to them. This optimization
improves performance of `getDirectives` significantly because text nodes
often result in expensive calls to `loadLContext` since we can't resolve
it from a parent node.
1. `getDirectives` now calls `loadLContext` with second argument `false`
so it doesn't throw an error. This brings another significant
improvement because prevents the VM from deoptimizing calls.
BREAKING CHANGE:
Previously the `ng.getDirectives` function threw an error in case a
given DOM node had no Angular context associated with it (for example
if a function was called for a DOM element outside of an Angular app).
This behavior was inconsistent with other debugging utilities under `ng`
namespace, which handled this situation without raising an exception.
Now calling the `ng.getDirectives` function for such DOM nodes would
result in an empty array returned from that function.
PR Close#41525
This commit introduces a global debugging method
`ng.getDirectiveMetadata` which returns the metadata for a directive or
component instance.
PR Close#41525
This adds string literals, number literals, `true`, `false`, `null` and
`undefined` to autocomplete results in templates.
For example, when completing an input of union type.
Component: `@Input('input') input!: 'a'|'b'|null;`
Template: `[input]="|"`
Provide `'a'`, `'b'`, and `null` as autocompletion entries.
Previously we did not include literal types because we only included
results from the component context (`ctx.`) and the template scope.
PR Close#41456
There were three options being made available to users of the linker:
- ` enableI18nLegacyMessageIdFormat`
- `i18nNormalizeLineEndingsInICUs`
- ` i18nUseExternalIds`
None of these should actually be configurable at linking time
because partially-linked libraries have tighter restrictions on
what i18n options can be used.
This commit removes those options from the `LinkerOptions` interface.
It was considered to add a check for backwards compatibilty to ensure
that if these options were being passed, and were different to the expected
defaults, we would throw an informative error. But from looking at the
Angular CLI (the only known client of the linker) it has never been setting
these options so they have already always been set to the defaults.
BREAKING CHANGE:
Linked libraries no longer generate legacy i18n message ids. Any downstream
application that provides translations for these messages, will need to
migrate their message ids using the `localize-migrate` command line tool.
Closes#40673
PR Close#41554
This commit has the Language Service take advantage of versioned source
files added in the compiler previously. With this change, the Language
Service's incremental compilations will now be correct even if the TS
Language service mutates `ts.SourceFile`s without changing their object
identity, as we know it does in certain corner cases.
No test is added here as it is difficult to reproduce this behavior in the
LS's artificial testing environment. A test for this case exists in the
LS extension repo, where it will be used to validate that a workaround three
is no longer necessary.
PR Close#41475
Generally, the compiler assumes that `ts.SourceFile`s are immutable objects.
If a new `ts.Program` is compared to an old one, and a `ts.SourceFile`
within that program has not changed its object identity, the compiler will
assume that its prior analysis and understanding of that source file is
still valid.
However, not all TypeScript workflows uphold this assumption. For
`ts.Program`s that originate from the `ts.LanguageService`, some source
files may be re-parsed or otherwise undergo mutations without changing their
object identity. This breaks the compiler's incremental workflow.
Within such environments, it's necessary to track source file changes
differently. In addition to object identity, it's necessary to compare a
"version" string associated with each source file, between when that file is
analyzed originally and when a new program is presented that still contains
it. It's possible for the object identity of the source file to be the same,
but the version string to have changed, indicating that the source file
should be treated as changed.
This commit adds an optional method `getSourceFileVersion` to the
`ProgramDriver`, to provide access to version information if available. When
this method is present, the compiler will build a map of source file version
strings, and use this map to augment identity comparison during incremental
compilation.
PR Close#41475
This commit replaces the `IncrementalDriver` abstraction which powered
incremental compilation in the compiler with a new `IncrementalCompilation`
design. Principally, it separates two concerns which were tied together in
the previous implementation:
1. Tracking the reusable state of a compilation at any given point that
could be reused in a subsequent future compilation.
2. Making use of a prior compilation's state to accelerate the current one.
The new abstraction adds explicit tracking and types to deal with both of
these concerns separately, which greatly reduces the complexity of the state
tracking that `IncrementalDriver` used to perform.
PR Close#41475
The compiler frequently translates TypeScript source file `fileName` strings
into absolute paths, via a `fs.resolve()` operation. This is often done via
the helper function `absoluteFromSourceFile`.
This commit adds a caching mechanism whereby the `AbsoluteFsPath` of a
source file is patched onto the object under an Angular-specific symbol
property, allowing the compiler to avoid resolving the path on subsequent
calls.
PR Close#41475
This commit implements signature help in the Language Service, on top of
TypeScript's implementation within the TCB.
A separate PR adds support for translation of signature help data from TS'
API to the LSP in the Language Service extension.
PR Close#41581
This commit changes `getTemplateAtTarget` to be able to identify when a
cursor position is specifically within the argument span of a `MethodCall`
or `SafeMethodCall` with no arguments. If the call had arguments, one of the
argument expressions would be returned instead, but in a call with no
arguments the tightest node _is_ the `MethodCall`. Adding the additional
argument context will allow for functionality that relies on tracking
argument positions, like `getSignatureHelpItems`.
PR Close#41581
`EmptyExpr` is somewhat unique, in that it's constructed in a circumstance
where the parser has been looking for a particular token or string of tokens
and has failed to find any. This means the parser state when constructing
`EmptyExpr` is fairly unique.
This gives rise to a bug where the parser constructs `EmptyExpr` with a
backwards span - a `start` value that's beyond the `end` value. This likely
happens because of the strange state the parser is in when recovering with
`EmptyExpr`.
This commit adds a backstop/workaround to avoid constructing such broken
`EmptyExpr` spans (or any other kind of span). Eventually, the parser state
should be fixed such that this does not occur, but that requires a
significant change to the parser's functionality, so a simple fix in th
interim is in order.
PR Close#41581
This commit adds a separate span to `MethodCall` and `SafeMethodCall` which
tracks the text span between the `(` and `)` tokens of the call. Tools like
the Language Service can use this span to more accurately understand a
cursor position within a method call expression.
PR Close#41581
When an Ivy NgModule is imported into a View Engine build, it doesn't have
metadata.json files that describe it as an NgModule, so it appears to VE
builds as a plain, undecorated class. The error message shown in this
situation generic and confusing, since it recommends adding an @NgModule
annotation to a class from a library.
This commit adds special detection into the View Engine compiler to give a
more specific error message when an Ivy NgModule is imported.
PR Close#41534
In the compiler, the `NgtscProgram` is responsible for creating the
`ts.Program` instance to use, potentially using a `ts.Program` from a
prior compilation to enable incremental compilation. It used to track
a `reuseTsProgram` for this purpose, however the `ts.Program` that
should be used as reuse program is also tracked by the `NgCompiler`
instance that is used by `NgtscProgram`. The `NgtscProgram` can leverage
the state from `NgCompiler` instead of keeping track of it by itself.
PR Close#41289
When multiple occurrences of the same package exist within a single
TypeScript compilation unit, TypeScript deduplicates the source files
by introducing redirected source file proxies. Such proxies are
recreated during an incremental compilation even if the original
declaration file did not change, which caused the compiler not to reuse
any work from the prior compilation.
This commit changes the incremental driver to recognize a redirected
source file and treat them as their unredirected source file.
PR Close#41448
In environments such as the Language Service where inline type-checking code
is not supported, the compiler would previously produce a diagnostic when a
template would require inlining to check. This happened whenever its
component class had generic parameters with bounds that could not be safely
reproduced in an external TCB. However, this created a bad user experience
for the Language Service, as its features would then not function with such
templates.
Instead, this commit changes the compiler to use the same strategy for
inline TCBs as it does for inline type constructors - falling back to `any`
for generic types when inlining isn't available. This allows the LS to
support such templates with slightly weaker type-checking semantics, which
a test verifies. There is still a case where components that aren't
exported require an inline TCB, and the compiler will still generate a
diagnostic if so.
Fixes#41395
PR Close#41513
Previously, the `DefaultImportRecorder` interface was used as follows:
1. During the analysis phase, the default import declaration of an
identifier was recorded.
2. During the emit phase each emitted identifier would be recorded.
The information from step 1 would then be used to determine the
default import declaration of the identifier which would be
registered as used.
3. A TypeScript transform would taint all default imports that were
registered as used in step 2 such that the imports are not elided
by TypeScript.
In incremental compilations, a file may have to be emitted even if its
analysis data has been reused from the prior compilation. This would
mean that step 1 is not executed, resulting in a mismatch in step 2 and
ultimately in incorrectly eliding the default. This was mitigated by
storing the mapping from identifier to import declaration on the
`ts.SourceFile` instead of a member of `DefaultImportTracker` such that
it would also be visible to the `DefaultImportRecorder` of subsequent
compiles even if step 1 had not been executed.
Ultimately however, the information that is being recorded into the
`DefaultImportRecorder` has a longer lifetime than a single
`DefaultImportRecorder` instance, as that is only valid during a single
compilation whereas the identifier to import declaration mapping
outlives a single compilation. This commit replaces the registration of
this mapping by attaching the default import declaration on the output
AST node that captures the identifier. This enables the removal of
all of the `DefaultImportRecorder` usages throughout the analysis phase
together with the `DefaultImportRecorder` interface itself.
PR Close#41557
The Angular compiler has to actively keep default import statements
alive if they were only used in type-only positions, but have been
emitted as value expressions for DI purposes. A problem occurred in
incremental recompilations, where the relationship between an identifier
usage and its corresponding default import would not be considered. This
could result in the removal of the default import statement and caused
a `ReferenceError` at runtime.
This commit fixes the issue by storing the association from an
identifier to its default import declaration on the source file itself,
instead of within the `DefaultImportTracker` instance. The
`DefaultImportTracker` instance is only valid for a single compilation,
whereas the association from an identifier to a default import
declaration is valid as long as the `ts.SourceFile` is the same
instance.
A subsequent commit refactor the `DefaultImportTracker` to no longer
be responsible for registering the association, as its lifetime is
conceptually too short to do so.
Fixes#41377
PR Close#41557
The `emitDecoratorMetadata` compiler option does not have to be enabled
as Angular decorators are transformed by the AOT compiler. Having the
option enabled in our tests can hide issues around import preservation,
as with `emitDecoratorMetadata` enabled the TypeScript compiler itself
does not elide imports even if they are only used in type-positions.
This is unlike having `emitDecoratorMetadata` disabled, however; in that
case the Angular compiler has to actively trick TypeScript into
retaining default imports when an identifier in a type-only position has
been reified into a value position for DI purposes.
A subsequent commit addresses a bug in default import preservation
that relies on this flag being `false`.
PR Close#41557
With this change we update several dependencies to avoid Renovate creating a lot of PRs during onboarding. We also remove yarn workspaces as after further analysis these are not needed.
Certain dependencies such as `@octokit/rest`, `remark` and `@babel/*` have not been updated as they require a decent amount of work to update, and it's best to leave them for a seperate PR.
PR Close#41434
This commit refactors the generated code for class metadata in partial
compilation mode. Instead of emitting class metadata into a top-level
`ɵsetClassMetadata` call guarded by `ngDevMode` flags, the class
metadata is now declared using a top-level `ɵɵngDeclareClassMetadata`
call.
PR Close#41200
This commit marks the `compilationMode` compiler option as stable, such
that libraries can be compiled in partial compilation mode.
In partial compilation mode, the compiler's output changes from fully
compiled AOT definitions to an intermediate form using partial
declarations. This form is suitable to be published to NPM, which now
allows libraries to be compiled and published using the Ivy compiler.
Please be aware that libraries that have been compiled using this mode
can only be used in Angular 12 applications and up; they cannot be used
when Ivy is disabled (i.e. when using View Engine) or in versions of
Angular prior to 12. The `compilationMode` option has no effect if
`enableIvy: false` is used.
Closes#41496
PR Close#41518
Fixes an error that will be thrown if `DebugRenderer2.destroyNode` is called with a node that has already been destroyed. The error happened, because we had a non-null assertion, even though the value can be null.
Note that this fix applies only to ViewEngine, because Ivy doesn't provide the `DebugRenderer2`. I decided to resolve it, because it fix is straightforward and this error has been showing up in our logs for a long time now, making actual errors harder to find.
PR Close#41565
With the work done in #41291, the compiler always tracks the last known
program, so there's no need to track the program in the compiler factory
anymore.
PR Close#41517
This commit adds a base class that contains common logic for all ControlValueAccessors defined in Forms package. This allows to remove duplicated logic from all built-in ControlValueAccessor classes.
PR Close#41225
This commit removes the line to set `currentNavigation` to `null` in the
navigation transitions subscription of the router. This logic is
already handled in the `finalize` stage of the transition pipe and has
been found to cause issues if a new navigation is triggered from a
subscription to the `NavigationEnd` event.
fixes#37460
PR Close#41262
`NgCompiler` previously had a notion of the "next" `ts.Program`, which
served two purposes:
* it allowed a client using the `ts.createProgram` API to query for the
latest program produced by the previous `NgCompiler`, as a starting
point for building the _next_ program that incorporated any new user
changes.
* it allowed the old `NgCompiler` to be queried for the `ts.Program` on
which all prior state is based, which is needed to compute the delta
from the new program to ultimately determine how much of the prior
state can be reused.
This system contained a flaw: it relied on the `NgCompiler` knowing when
the `ts.Program` would be changed. This works fine for changes that
originate in `NgCompiler` APIs, but a client of the `TemplateTypeChecker`
may use that API in ways that create new `ts.Program`s without the
`NgCompiler`'s knowledge. This caused the `NgCompiler`'s concept of the
"next" program to get out of sync, causing incorrectness in future
incremental analysis.
This refactoring cleans up the compiler's `ts.Program` management in
several ways:
* `TypeCheckingProgramStrategy`, the API which controls `ts.Program`
updating, is renamed to the `ProgramDriver` and extracted to a separate
ngtsc package.
* It loses its responsibility of determining component shim filenames. That
functionality now lives exclusively in the template type-checking package.
* The "next" `ts.Program` concept is renamed to the "current" program, as
the "next" name was misleading in several ways.
* `NgCompiler` now wraps the `ProgramDriver` used in the
`TemplateTypeChecker` to know when a new `ts.Program` is created,
regardless of which API drove the creation, which actually fixes the bug.
PR Close#41291
This commit changes the partial compilation so that it outputs declarations
rather than definitions for injectables.
The JIT compiler and the linker are updated to be able to handle these
new declarations.
PR Close#41316
The other similar interfaces were renamed in https://github.com/angular/angular/pull/41119,
but this one was left since it had existed before Ivy. It looks like the interface was
never actually exposed on npm so it is safe to rename this one too.
PR Close#41316
When we deactivate a child route, we deactivate its outlet as well as
its children. We also need to clear the stored information about the
route and the associated component.
If we do not, the context will keep these references and can result in
reactivating an outlet that was deactivated by the previous navigation.
Fixes#41379
PR Close#41381
Pete Bacon Darwin
Renovate Bot
Kristiyan Kostadinov
Alan Agius
Paul Gschwendtner
Emily Wenberg
Andrew Kushnir
JiaLiPassion
Ajit Singh
Zach Arend
Julien Marcou
jeripeierSBB
Dmitrij Kuba
Martin Sikora
Andrew Scott
Charles Lyding
Joey Perrott
mgechev
Alex Rickabaugh
JoostK
Benjamin Kindle
Keen Yee Liau