Currently the `ngForOf` input accepts `null` or `undefined` as valid
values. Although when using strict template input type checking
(which will be supported by `ngtsc`), passing `null` or `undefined`
with strict null checks enabled causes a type check failure because
the type for the `ngForOf` input becomes too strict if strict null checks
are enabled. The type of the input needs to be expanded to also accept
`null` or `undefined` to behave consistently regardless of the
`strictNullChecks` flag.
This is necessary because whenever strict input type checking is enabled
by default, most of the Angular projects that use `*ngFor` with the async pipe
will either need to disable template type checking or strict null checks
because the `async` pipe returns `null` if the observable hasn't been
emitted yet.
See for example how this affects the `angular/components` repository and
how much bloat the workaround involves: https://github.com/angular/components/pull/16373/files#r296942696.
PR Close#31371
In View Engine, animation metadata could occur in nested arrays which
would be flattened in the compiler. When compiling a component for Ivy
however, the compiler no longer statically evaluates a component's
animation metadata and is therefore unable to flatten it statically.
This resulted in an issue to find animations at runtime, as the metadata
was incorrectly registered with the animation engine.
Although it would be possible to statically evaluate the animation
metadata in ngtsc, doing so would prevent reusable animations exported
from libraries from being usable as ngtsc's partial evaluator is unable
to read values inside libraries. This is unlike ngc's usage of static
symbols represented in a library's `.metadata.json`, which explains how
the View Engine compiler is able to flatten the animation metadata
statically.
As an alternative solution, the metadata flattening is now done in the
runtime during the registration of the animation metadata with the
animation engine.
Fixes#32794
PR Close#32818
As mentioned in the previous commit, the regexp used by
`Validators.email()` is a slightly enhanced version of the
[WHATWG one](https://html.spec.whatwg.org/multipage/input.html#valid-e-mail-address).
This commit refactors the regexp (without changing its behavior) to make
it more closely match the format of WHATWG version, so that it is easier
for people to compare it against the WHATWG one and understand the
differences.
The main changes were:
- Changing the order of characters/character classes inside `[...]`;
e.g. `[A-Za-z]` --> `[a-zA-Z]`
- Mark all groups as non-capturing (since we do not use the captured
values); e.g. `(foo)` --> `(?:foo)`
(This could theoretically also have a positive performance impact, but
I suspect JavaScript engines are already optimizing away capturing
groups when they are not used.)
PR Close#32961
Previously, there was no documentation of what `Validators.email()`
expects as a valid e-mail address, making it difficult for people to
determine whether it covers their requirements or not. Even more so that
the used pattern slightly deviates from the
[WHATWG version](https://html.spec.whatwg.org/multipage/input.html#valid-e-mail-address).
One's only option was to look at the source code and try to decipher the
regexp pattern.
This commit adds a high-level description of the validator and mentions
its similarity to and differences from the WHATWG version. It also adds
a brief explanation of the regexp's behavior and references for more
information in the source code to provide more context to
maintainers/users trying to understand the implementation in the future.
Fixes#18985Fixes#25186Closes#32747
PR Close#32961
Prior to this change, ng-reflect properties were not created in case an attribute was marked as translatable (for ex. `i18n-title`). This commit adds the logic to generate ng-reflect for such cases.
PR Close#32989
The schematics added in #32791 is currently failing as the package.json does not reference it.
```
> ng add @angular/localize@9.0.0-next.9
+ @angular/localize@9.0.0-next.9
added 1 package from 1 contributor in 6.745s
Installed packages for tooling via npm.
The package that you are trying to add does not support schematics. You can try using a different version of the package or contact the package author to add ng-add support.
```
PR Close#33025
Prior to this commit, the `ng` was exposed in global namespace, which turned out to be problematic when minifying code with Closure, since it sometimes clobber our `ng` global. This commit aligns Ivy debugging tools behavior with existing logic in "platform-browser" package (packages/platform-browser/src/dom/util.ts#L31) by avoiding `ng` in global namespace when Closure Compiler is used.
PR Close#33010
Re-enables the dynamic queries migration, now that we have all of the necessary framework changes in place.
Also moves the logic that identifies static queries out of the compiler and into the static queries migration, because that's the only place left that's using it.
PR Close#32992
Followup to #32720 that removed the logic that statically determines whether a query is dynamic.
This updates the docs to reflect that, and mentions that the flag now defaults to false.
PR Close#32993
Current we need to create and override certain compiler host methods in every schematic because schematics use a virtual fs. We this change we extract this logic to a common util.
PR Close#32827
Not sure why it works on other people's environments, but after
217db9b21 I started getting the following error when running
`scripts/build-packages-dist.sh` (on Windows):
```
ERROR: C:/.../angular/packages/bazel/docs/BUILD.bazel:3:1: Generating Skylark documentation dir for docs (3 files) failed (Exit 1)
Traceback (most recent call last):
File "c:\...\temp\Bazel.runfiles_u_l5te\runfiles\io_bazel_skydoc\skydoc\main.py", line 335, in <module>
main(sys.argv)
File "c:\...\temp\Bazel.runfiles_u_l5te\runfiles\io_bazel_skydoc\skydoc\main.py", line 303, in main
load_symbols = load_sym_extractor.extract(bzl_file)
File "c:\...\temp\Bazel.runfiles_u_l5te\runfiles\io_bazel_skydoc\skydoc\load_extractor.py", line 110, in extract
load_symbols = self._extract_loads(bzl_file)
File "c:\...\temp\Bazel.runfiles_u_l5te\runfiles\io_bazel_skydoc\skydoc\load_extractor.py", line 38, in _extract_loads
tree = ast.parse(f.read(), bzl_file)
File "C:\...\.windows-build-tools\python27\lib\ast.py", line 37, in parse
return compile(source, filename, mode, PyCF_ONLY_AST)
File "packages/bazel/src/ng_package/ng_package.bzl", line 39
print("[ng_package.bzl]", *args)
^
SyntaxError: invalid syntax
```
It seems expected, because `print` is not a function, so
`print(foo, *args)` is interpreted as printing a tuple (where `*args` is
invalid syntax). Not sure why it doesn't break on other people's
machines :/
This change makes the verbose logs a little less pretty, but that
shouldn't be a big issue (given that it is an opt-in feature and it can
always be overwritten locally, if necessary).
PR Close#32923
The creation of StaticReflector in createMetadataResolver() is a very expensive operation because it involves numerous module resolutions.
To make matter worse, since the API of the Reflector does not provide the ability to invalidate its internal caches, it has to be destroyed and recreated on *every* program change.
This has a HUGE impact on performance.
This PR fixes this problem by carefully invalidating all StaticSymbols in a file that has changed, thereby reducing the overhead of recomputation on program change.
PR Close#32543
This is a re-submit of #32686.
Switches back to having the static flag be optional on ViewChild and ContentChild queries, in preparation for changing its default value.
PR Close#32986
These changes switch to defaulting the `static` flag on `ViewChild` and `ContentChild` queries to `false`, in addition to removing the logic that statically determines whether a query is dynamic.
PR Close#32720
The `$localize` library uses a new message digest function for
computing message ids. This means that translations in legacy
translation files will no longer match the message ids in the code
and so will not be translated.
This commit adds the ability to specify the format of your legacy
translation files, so that the appropriate message id can be rendered
in the `$localize` tagged strings. This results in larger code size
and requires that all translations are in the legacy format.
Going forward the developer should migrate their translation files
to use the new message id format.
PR Close#32937
Add unit test coverage for new logic added in #32874 and for existing
logic that was untested.
test(upgrade): add unit tests for AngularJSUrlCodec's parse method
Add additional coverage and fix spacing
test(upgrade): add unit tests for AngularJSUrlCodec's parse method
Add unit test coverage for new logic added in #32874 and for existing
logic that was untested.
test(upgrade): add unit tests for AngularJSUrlCodec's parse method
Add additional coverage and fix spacing
test(upgrade): add unit tests for AngularJSUrlCodec's parse method
Add unit test coverage for new logic added in #32874 and for existing
logic that was untested.
test(upgrade): add unit tests for AngularJSUrlCodec's parse method
Add unit test coverage for new logic added in #32874 and for existing
logic that was untested.
test(upgrade): add unit tests for AngularJSUrlCodec's parse method
Add additional coverage and fix spacing
test(upgrade): add unit tests for AngularJSUrlCodec's parse method
Add unit test coverage for new logic added in #32874 and for existing
logic that was untested.
PR Close#32976
This PR updates Angular to compile with TypeScript 3.6 while retaining
compatibility with TS3.5. We achieve this by inserting several `as any`
casts for compatiblity around `ts.CompilerHost` APIs.
PR Close#32908
Currently the undecorated-classes-with-di migration leverages NGC in order
to work with metadata resolution. Since NGC by default tries to resolve referenced
resources on initialization of the underlying TS program, it can result in unexpected
migration failures due to missing resource files.
This is especially an issue since the CLI wraps the `AngularCompilerProgram` with
special logic (i.e. to support SCSS preprocessing etc.). We don't have all of this since
we instantiate a vanilla NGC program.
The solution to the problem is to simply treat resource requests as valid, and returning
a fake content. The migration is not dependent on templates or stylesheets.. so it's the
simplest and most robust solution.
Fixes#32826
PR Close#32953
ec4381d explicitly set `enableIvy: false` for all migrations inside
the core package. This actually hides migration issues because the
migration itself should ensure that it instantiates the right
compiler program if it relies on `@angular/compiler-cli`.
We should remove these options from all migration tests to
ensure that we catch issues with migrations running in version
9 where Ivy is enabled by default.
e.g. e5636a322c
was accidentally hidden due to the `enableIvy: false` option.
PR Close#32954
ec4381d enabled Ivy by default. This is problematic as migrations
like `static-queries` depend on the `AngularCompilerProgram` (NGC)
in order to perform the migration from version 7 to version 8.
In order to ensure that the migration always runs with NGC
(and doesn't get the `NgtscProgram`), we need to explicitly disable
ivy when creating the `@angular/compiler-cli` program for the migration.
This code is still relevant even though the update from version 7
to version 8 landed. Developers can run `ng update` from version 7
and immediately get to version 9 where Ivy is enabled by default (and in
that case we need to ensure that ngtsc is not accidentally used).
Similar to
e5636a322c.
PR Close#32954
In an attempt to be compatible with previous translation files
the Angular compiler was generating instructions that always
included the message id. This was because it was not possible
to accurately re-generate the id from the calls to `$localize()` alone.
In line with https://hackmd.io/EQF4_-atSXK4XWg8eAha2g this
commit changes the compiler so that it only renders ids if they are
"custom" ones provided by the template author.
NOTE:
When translating messages generated by the Angular compiler
from i18n tags in templates, the `$localize.translate()` function
will compute message ids, if no custom id is provided, using a
common digest function that only relies upon the information
available in the `$localize()` calls.
This computed message id will not be the same as the message
ids stored in legacy translation files. Such files will need to be
migrated to use the new common digest function.
This only affects developers who have been trialling `$localize`, have
been calling `loadTranslations()`, and are not exclusively using custom
ids in their templates.
PR Close#32867
Metadata blocks are delimited by colons. Previously the code naively just
looked for the next colon in the string as the end marker.
This commit supports escaping colons within the metadata content.
The Angular compiler has been updated to add escaping as required.
PR Close#32867
Previously the metadata and placeholder blocks were serialized in
a variety of places. Moreover the code for creating the `LocalizedString`
AST node was doing serialization, which break the separation of concerns.
Now this is all done by the code that renders the AST and is refactored into
helper functions to avoid repeating the behaviour.
PR Close#32867
Previously if a translation contains a placeholder that
does not exist in the message being translated, that
placeholder is evaluated as `undefined`.
Translations should never contain such placeholder names
so now `translate` will throw a helpful error in instead.
PR Close#32867
Adds information about the NgModule a Directive is declared in when the
Directive class name is hovered over, in the form
```
(directive) NgModule.Directive: class
```
Closes#32565
PR Close#32763
Similarly to `ts_library` compilation actions, the `ng_module` compile action should include
the current compile mode in the action description. This makes it consistent with `ts_library`
targets and also avoids confusion when both output flavors are requested.
Currently when both output flavors are requested (e.g. in the `ng_package` rule), both
devmode and prodmode compilations have the same action name. This is confusing and
looks like the given target is built *twice* due to a bug (which is obviously not the case though)
PR Close#32955
With #31953 we moved the factories for components, directives and pipes into a new field called `ngFactoryDef`, however I decided not to do it for injectables, because they needed some extra logic. These changes set up the `ngFactoryDef` for injectables as well.
For reference, the extra logic mentioned above is that for injectables we have two code paths:
1. For injectables that don't configure how they should be instantiated, we create a `factory` that proxies to `ngFactoryDef`:
```
// Source
@Injectable()
class Service {}
// Output
class Service {
static ngInjectableDef = defineInjectable({
factory: () => Service.ngFactoryFn(),
});
static ngFactoryFn: (t) => new (t || Service)();
}
```
2. For injectables that do configure how they're created, we keep the `ngFactoryDef` and generate the factory based on the metadata:
```
// Source
@Injectable({
useValue: DEFAULT_IMPL,
})
class Service {}
// Output
export class Service {
static ngInjectableDef = defineInjectable({
factory: () => DEFAULT_IMPL,
});
static ngFactoryFn: (t) => new (t || Service)();
}
```
PR Close#32433
Safari throws an error when the new URL() constructor is called with an
undefined base. This change checks whether the base is undefined and
then calls the corresponding version of the URL constructor.
fix(upgrade): simplify solution by replacing undefined with ''
Co-Authored-By: Pete Bacon Darwin <pete@bacondarwin.com>
Simplify solution by replacing undefined with ''
Co-Authored-By: Pete Bacon Darwin <pete@bacondarwin.com>
fix(upgrade): Avoid passing an empty string as the base as well.
Browsers other than Safari may have issues with the empty string.
PR Close#32959
Switches back to having the `static` flag be optional on `ViewChild` and `ContentChild` queries, in preparation for changing its default value.
PR Close#32686
These changes switch to defaulting the `static` flag on `ViewChild` and `ContentChild` queries to `false`, in addition to removing the logic that statically determines whether a query is dynamic.
PR Close#32720
There are a couple scenarios that are problematic and need special
handling:
1. A user has a custom implementation of lazy-loaded modules, sets some
provider overrides, then compiles the module so it can be loaded. In a
follow-up test, the user sets different overrides for the module and
then compiles. This is problematic because we need to be sure the module
registered in the first test is not used, so we need to clear it out of
the modules list in `ng_module_factory_registration`.
2. A user has a similar lazy-loaded module factory implementation but
relies on the module being registered automatically. This can happen,
for example, as a side effect of importing the ngfactory file.
PR Close#32944
Paul Gschwendtner
LASLEDJ
Kristiyan Kostadinov
JoostK
George Kalpakas
Andrew Kushnir
cexbrayat
Charles Lyding
JiaLiPassion
Alan
Pawel Kozlowski
JiaLiPassion
Keen Yee Liau
Andrius
Pete Bacon Darwin
Alison Gale
Martin Probst
ayazhafiz
Kara Erickson
Niklas Merz
atscott
Alan Agius
Andrew Scott