The template type checking abilities of the Ivy compiler are far more
advanced than the level of template type checking that was previously
done for Angular templates. Up until now, a single compiler option
called "fullTemplateTypeCheck" was available to configure the level
of template type checking. However, now that more advanced type checking
is being done, new errors may surface that were previously not reported,
in which case it may not be feasible to fix all new errors at once.
Having only a single option to disable a large number of template type
checking capabilities does not allow for incrementally addressing newly
reported types of errors. As a solution, this commit introduces some new
compiler options to be able to enable/disable certain kinds of template
type checks on a fine-grained basis.
PR Close#33365
View Engine correctly infers the type of local refs to directives or to
<ng-template>s, just not to DOM nodes. This commit splits the
checkTypeOfReferences flag into two separate halves, allowing the compiler
to align with this behavior.
PR Close#33365
For elements that have a text attribute, it may happen that the element
is matched by a directive that consumes the attribute as an input. In
that case, the template type checker will validate the correctness of
the attribute with respect to the directive's declared type of the
input, which would typically be `boolean` for the `disabled` input.
Since empty attributes are assigned the empty string at runtime, the
template type checker would report an error for this template.
This commit introduces a strictness flag to help alleviate this
particular situation, effectively ignoring text attributes that happen
to be consumed by a directive.
PR Close#33365
During the creation of an Angular program in the compiler, a check is
done to verify whether the version of TypeScript is considered
supported, producing an error if it is not. This check was missing in
the Ivy compiler, so users may have ended up running an unsupported
TypeScript version inadvertently.
Resolves FW-1643
PR Close#33377
`LFrame` stores information specifice to the current `LView` As the code
enters and leaves `LView`s we use `enterView()` and `leaveView()`
respectively to build a a stack of `LFrame`s. This allows us to easily
restore the previous `LView` instruction state.
PR Close#33178
It is messy to keep casting `CompletionEntry.kind` from
`ng.CompletionKind` to `ts.ScriptElementKind`.
Instead, create a new type `ng.CompletionEntry` that is exactly the same
as `ts.CompletionEntry`, but with the `kind` type overridden to
`ng.CompletionKind`.
This way, we only have to cast it once, and can do so in a safe manner.
PR Close#33379
Recently it was made possible to have a directive without selector,
which are referred to as abstract directives. Such directives should not
be registered in an NgModule, but can still contain decorators for
inputs, outputs, queries, etc. The information from these decorators and
the `@Directive()` decorator itself needs to be registered with the
central `MetadataRegistry` so that other areas of the compiler can
request information about a given directive, an example of which is the
template type checker that needs to know about the inputs and outputs of
directives.
Prior to this change, however, abstract directives would only register
themselves with the `MetadataRegistry` as being an abstract directive,
without all of its other metadata like inputs and outputs. This meant
that the template type checker was unable to resolve the inputs and
outputs of these abstract directives, therefore failing to check them
correctly. The typical error would be that some property does not exist
on a DOM element, whereas said property should have been bound to the
abstract directive's input.
This commit fixes the problem by always registering the metadata of a
directive or component with the `MetadataRegistry`. Tests have been
added to ensure abstract directives are handled correctly in the
template type checker, together with tests to verify the form of
abstract directives in declaration files.
Fixes#30080
PR Close#33131
During compile-time translation inlining, the `$localize.locale`
expression will now be replaced with a string literal containing the
current locale of the translations.
PR Close#33314
In the post-$localize world the current locale value is defined by setting
`$localize.locale` which is then read at runtime by Angular in the provider
for the `LOCALE_ID` token and also passed to the ivy machinery via`setLocaleId()`.
The $localize compile-time inlining tooling can replace occurrences of
`$localize.locale` with a string literal, similar to how translations
are inlined.
// FW-1639
See https://github.com/angular/angular-cli/issues/15896
PR Close#33314
Previously, when one wanted to try out the changes from a PR before it
was merged, they had to check out the PR locally and build the Angular
packages themselves (which is time-consuming and wasteful given that the
packages have already been built on CI).
This commit persists all Angular packages on each build as `.tgz` files,
which can be used to install dependencies on an project (supported by
both [npm][1] and [yarn][2]). In addition to individual `.tgz` files for
each package, a `.tgz` file including all packages is also stored, which
can be used to test the packages locally by overwriting the ones in the
`node_modules/` directory of a project.
CircleCI [build artifacts][3] an be used for longer-term storage of the
outputs of a build and are designed to be useful around the time of the
build, which suits our needs.
[1]: https://docs.npmjs.com/cli/install.html
[2]: https://yarnpkg.com/lang/en/docs/cli/add
[3]: https://circleci.com/docs/2.0/artifacts
PR Close#33321
Previously, we had tested that expressions parsed in a Render3 AST
had correctly-defined absolute spans (spans relative to the entire
template, not the local expression). Sometimes we use Template ASTs
rather than Render3 ASTs, and it's desirable to test for correct
expression spans in the template parser as well.
Adding these tests resolved one bug, similar to the one fixed in
fd4fed14d8, where expressions in the value
of a template attribute were not given an absolute span corresponding to
the start of the attribute name rather than the start of the attribute
value.
The diff on this commit is large, partially because it involves some
structural changes of the template parser testing layout. In particular,
the following is done:
1. Move `createMeta*`-like functions from `template_parser_spec.ts` to
be exported from a new test utility file.
2. Create an `ExpressionSourceHumanizer`, similar to the one created in
b04488d692, to allow convenient testing
of expressions' locations.
3. Create `template_parser_absolute_span_spec.ts`, testing the spans of
expressions parsed by the template parser. This is very similar to
the `r3_ast_absolute_span_spec`.
PR Close#33253
Often the types of an `@Input`'s field don't fully reflect the types of
assignable values. This can happen when an input has a getter/setter pair
where the getter always returns a narrow type, and the setter coerces a
wider value down to the narrow type.
For example, you could imagine an input of the form:
```typescript
@Input() get value(): string {
return this._value;
}
set value(v: {toString(): string}) {
this._value = v.toString();
}
```
Here, the getter always returns a `string`, but the setter accepts any value
that can be `toString()`'d, and coerces it to a string.
Unfortunately TypeScript does not actually support this syntax, and so
Angular users are forced to type their setters as narrowly as the getters,
even though at runtime the coercion works just fine.
To support these kinds of patterns (e.g. as used by Material), this commit
adds a compiler feature called "input coercion". When a binding is made to
the 'value' input of a directive like MatInput, the compiler will look for a
static field with the name ngAcceptInputType_value. If such a field is found
the type-checking expression for the input will use the static field's type
instead of the type for the @Input field,allowing for the expression of a
type conversion between the binding expression and the value being written
to the input's field.
To solve the case above, for example, MatInput might write:
```typescript
class MatInput {
// rest of the directive...
static ngAcceptInputType_value: {toString(): string};
}
```
FW-1475 #resolve
PR Close#33243
Decrease `MIN_SAMPLE_DURATION` to make it more likely that we cane fit into single time slice.
Increase `MIN_SAMPLE_COUNT_NO_IMPROVEMENT` to make it more likely to find the best
PR Close#33341
change the existing implementation from using
```
string.split(/\s+/);
```
to a char scan which performers the same thing.
The reason why `split(/\s+/)` is slow is that:
- `/\s+/` allocates new `RegExp` every time this code executes.
- `RegExp` scans are a lot more expensive because they are more powerful.
PR Close#33326
Prior to this change, a method call of a local template variable would
incorrectly be considered a call to a method on the component class.
For example, this pattern would produce an error:
```
<ng-template let-method>{{ method(1) }}</ng-template>
```
Here, the method call should be targeting the `$implicit` variable on
the template context, not the component class. This commit corrects the
behavior by first resolving methods in the template before falling back
on the component class.
Fixes#32900
PR Close#33132
In View Engine, with fullTemplateTypeCheck mode disabled, the type of any
inferred based on the entity being referenced. This is a bug, since the
goal with fullTemplateTypeCheck: false is for Ivy and VE to be aligned in
terms of type inference.
This commit adds a 'checkTypeOfReference' flag in the TypeCheckingConfig
to control this inference, and sets it to false when fullTemplateTypeCheck
is disabled.
PR Close#33261
PR#28396 originally addressed an update via issue #23983 to make images more visible with a white background (implementation of gray "lightbox").
This PR implements those styles defined in PR#28396.
PR Close#33259
Libraries can expose directive/component base classes that will be
used by consumer applications. Using such a base class from another
compilation unit works fine with "ngtsc", but when using "ngc", the
compiler will thrown an error saying that the base class is not
part of a NgModule. e.g.
```
Cannot determine the module for class X in Y! Add X to the NgModule to fix it.
```
This seems to be because the logic for distinguishing directives from
abstract directives is scoped to the current compilation unit within
ngc. This causes abstract directives from other compilation units to
be considered as actual directives (causing the exception).
PR Close#33347
In the example, there's no directive nor input that's named `appHighlightColor`.
It should be `appHighlight`, referring to the input binding.
PR Close#33331
This should be removed before for 9.0.0 rc
BREAKING CHANGE:
@angular/bazel ng_setup_workspace() is no longer needed and has been removed.
We assume you will fetch rules_nodejs in your WORKSPACE file, and no other dependencies remain here.
Simply remove any calls to this function and the corresponding load statement.
PR Close#33330
It looks like the gulp setup does not work with NodeJS v12. This
is because we still use gulp for a few tasks, but gulp v3 is not
compatible with NodeJS v12. We had a similar issue for NodeJS v12,
but worked around it by updating the `natives` module version.
To actually solve this in a more future-proof way, without
updating or removing Gulp (for now), we just overwrite the
`graceful-fs` version. The latest version of `graceful-fs`
does no longer depend on the `natives` package and therefore
works properly with NodeJS >= v10.
PR Close#33348
Previously, when navigating to a new page via a link, the scroll
position was correctly restored to 0, but navigating to a new page via
typing the URL in the browser address bar keeps the old scroll position.
This commit ensures that the scroll position is restored to 0 whenever
the `ScrollService` is instantiated anew (i.e. new page navigation). The
old behavior of retaining the scroll position on reload is kept by
storing the old URL when leaving a page and only applying the stored
scroll position if the new URL matches the stored one.
Fixes#33260
PR Close#33344
This commit adds a guide to AIO navigation for
"Migrating to Version 9" and moves the schematics
section into the guide that previously lived in
the deprecations page. It also pastes a snippet
of the deprecations page in the new guide so users
don't have to filter out deprecations they've seen
before.
Note: Ivy compatibility section is coming up in a
follow-up PR.
PR Close#33339
Miško Hevery
Kara Erickson
JoostK
Alex Rickabaugh
Pete Bacon Darwin
Keen Yee Liau
Greg Magolan
George Kalpakas
ayazhafiz
Geoff Bass
Andrus Diaz
Igor Minar
Andrew Kushnir
Stefanie Fluin
Paul Gschwendtner
ODAVING
Keen Yee Liau