To support compile time localization, we need to be
able to provide the locales via a well known global property.
This commit changes `getLocaleData()` so that it will attempt
to read the local from the global `ng.common.locales` if the
locale has not already been registered via `registerLocaleData()`.
PR Close#33523
To limit the exposure of the private `LOCALE_DATA` from outside
`@angular/core` this commit exposes private functions in the core
to hide the internal structures better.
* The `registerLocaleData()` implementation has moved from
`@angular/common` to `@angular/core`. A stub that delegates to
core has been left in common for backward compatibility.
* A new `ɵunregisterLocaleData()` function has been provided,
which is particularly useful in tests to clear out registered locales
to prevent subsequent tests from being affected.
* A private export of `ɵregisterLocaleData()` has been removed
from `@angular/common`. This was not being used and is accessible
via `@angular/core` anyway.
PR Close#33523
In order to support adding locales during compile-time
inlining of translations (i.e. after the TS build has completed),
we need to be able to attach the locale to the global scope.
This commit modifies CLDR extraction to emit additional "global"
locale files that appear in the `@angular/common/locales/global` folder.
These files are of the form:
```
(function() {
const root = typeof globalThis !== 'undefined' && globalThis ||
typeof global !== 'undefined' && global || typeof window !== 'undefined' && window;
root.ng = root.ng || {};
root.ng.common = root.ng.common || {};
root.ng.common.locale = root.ng.common.locale || {};
const u = undefined;
function plural(n) {
if (n === 1) return 1;
return 5;
}
root.ng.common.locale['xx-yy'] = [...];
})();
```
The IIFE will ensure that `ng.common.locale` exists and attach the
given locale (and its "extras") to it using it "normalized" locale
name.
* "extras": in the UMD module locale files the "extra" locale data,
currently the day period rules, and extended day period data, are
stored in separate files under the "common/locales/extra" folder.
* "normalized": Angular references locales using a normalized form,
which is lower case with `_` replaced by `-`. For example:
`en_UK` => `en-uk`.
PR Close#33523
When decorating classes with ivy definitions (e.g. `ɵfac` or `ɵdir`)
the inner name of the class declaration must be used.
This is because in ES5 the definitions are inside the class's IIFE
where the outer declaration has not yet been initialized.
PR Close#33533
In ES5 the class consists of an outer variable declaration that is
initialised by an IIFE. Inside the IIFE the class is implemented by
an inner function declaration that is returned from the IIFE.
This inner declaration may have a different name to the outer
declaration.
This commit overrides `getInternalNameOfClass()` and
`getAdjacentNameOfClass()` in `Esm5ReflectionHost` with methods that
can find the correct inner declaration name identifier.
PR Close#33533
When compiling an Angular decorator (e.g. Directive), @angular/compiler
generates an 'expression' to be added as a static definition field
on the class, a 'type' which will be added for that field to the .d.ts
file, and a statement adjacent to the class that calls `setClassMetadata()`.
Previously, the same WrappedNodeExpr of the class' ts.Identifier was used
within each of this situations.
In the ngtsc case, this is proper. In the ngcc case, if the class being
compiled is within an ES5 IIFE, the outer name of the class may have
changed. Thus, the class has both an inner and outer name. The outer name
should continue to be used elsewhere in the compiler and in 'type'.
The 'expression' will live within the IIFE, the `internalType` should be used.
The adjacent statement will also live within the IIFE, the `adjacentType` should be used.
This commit introduces `ReflectionHost.getInternalNameOfClass()` and
`ReflectionHost.getAdjacentNameOfClass()`, which the compiler can use to
query for the correct name to use.
PR Close#33533
This commit moves nested i18n section detection to an earlier stage where we convert HTML AST to Ivy AST. This also gives a chance to produce better diagnistic message for nested i18n sections, that also includes a file name and location.
PR Close#33583
This patch introduces a `firstUpdatePass` flag which can be used inside
of instruction code to determine if this is the first time each
instruction is running inside of the update block of a template or
a hostBindings function.
PR Close#31270
We already store a reference to a native host of a component
view so we can drop the getHostNative utility function (that
was getting the same reference from another data structure).
PR Close#33554
In ViewEngine we used to throw an error if we encountered an unknown element while rendering. We have this already for Ivy in AoT, but we didn't in JiT. These changes implement the error for JiT mode.
PR Close#33419
The 4b81bb5c97 patch seemingly broke the
`profile_all.js` file due to the file renaming. This patch restores the
functionality of said script.
PR Close#33494
These exports are no longer used by the CLI since 7.1.0. Since major versions of the CLI are now locked to major versions of the framework, a CLI user will not be able to use FW 9.0+ on an outdated version (<7.1.0) of the CLI that uses these old APIs.
PR Close#33242
During static evaluation of expressions within ngtsc, it may occur that
certain expressions or just parts thereof cannot be statically
interpreted for some reason. The static interpreter keeps track of the
failure reason and the code path that was evaluated by means of
`DynamicValue`, which will allow descriptive errors. In some situations
however, the static interpreter would throw an exception instead,
resulting in a crash of the compilation. Not only does this cause
non-descriptive errors, more importantly does it prevent the evaluated
result from being partial, i.e. parts of the result can be dynamic if
their value does not have to be statically available to the compiler.
This commit refactors the static interpreter to never throw errors for
certain expressions that it cannot evaluate.
Resolves FW-1582
PR Close#33453
Using the async pipe as the very first example makes it very confusing for beginners. Most people believe that | async is required for ngFor. I would remove that part to make the example solely focused on NgFor.
PR Close#33378
Previously the compiler would crash if a pipe was encountered which did not
match any pipe in the scope of a template.
This commit introduces a new diagnostic error for unknown pipes instead.
PR Close#33454
Previously the template binder would crash when encountering an unknown
localref (# reference) such as `<div #ref="foo">` when no directive has
`exportAs: "foo"`.
With this commit, the compiler instead generates a template diagnostic error
informing the user about the invalid reference.
PR Close#33454
- resolves "Invariant violated (initialize): latest hash null has no known manifest"
- Thanks to @gkalpak and @hsta for helping test and investigate this fix
Fixes#25611
PR Close#32525
Before this change instantiating multiple directives on the same
host node would result in repeated RNode retrieval and patching.
This commint re-organises code around directive instance creation
so the host node processing (common to all directives) happens
once and only once.
As the additional benefit the directive instantiation logic gets
centralised in one function (at the expense of patching logic
duplication for root node).
PR Close#33322
Previously declarations that were imported via a namespace import
were given the same `bestGuessOwningModule` as the context
where they were imported to. This causes problems with resolving
`ModuleWithProviders` that have a type that has been imported in
this way, causing errors like:
```
ERROR in Symbol UIRouterModule declared in
.../@uirouter/angular/uiRouterNgModule.d.ts
is not exported from
.../@uirouter/angular/uirouter-angular.d.ts
(import into .../src/app/child.module.ts)
```
This commit modifies the `TypescriptReflectionHost.getDirectImportOfIdentifier()`
method so that it also understands how to attach the correct `viaModule` to
the identifier of the namespace import.
Resolves#32166
PR Close#33495
Currently if one of the project targets could not be analyzed
due to AOT compiler program failures, we gracefully proceed
with the migration. This is expected, but we should not
print a message at the end of the migration that the migration
was _successful_. The migration was only done partially, hence
it's potentially incomplete and we should make it clear that once
the failures are resolved, the migration should be re-run.
PR Close#33315
Also removes `build:remote --spawn_strategy=remote` from .bazelrc. It seems that with Bazel 1.0.0 setting `--incompatible_list_based_execution_strategy_selection=false` no longer works around the issue with npm_package that it did when it was added. The error that was originally observed has returned after updating to Bazel 1.0.0:
```
ERROR: /home/circleci/ng/packages/angular_devkit/build_optimizer/BUILD:66:1: Assembling npm package packages/angular_devkit/build_optimizer/npm_package failed: No usable spawn strategy found for spawn with mnemonic Action. Your --spawn_strategy, --genrule_strategy or --strategy flags are probably too strict. Visit https://github.com/bazelbuild/bazel/issues/7480 for migration advice
```
This commit removes both `—incompatible_list_based_execution_strategy_selection=false` as well as `build:remote --spawn_strategy=remote` which means that Bazel will do the default behavior of picking the first available strategy from the default list, which is `remote,worker,sandboxed,local`. See https://github.com/bazelbuild/bazel/issues/7480 for more details.
Not updating to Bazel 1.1.0 yet due to a docker permissions CI issue that was observed on the angular repo that is unresolved. See https://github.com/angular/angular/pull/33367#issuecomment-547643246.
PR Close#33476
Note: the @angular/bazel schematic now appends the package.json "script" field with 'ngcc --properties es2015 browser module main'. If there is an existing script field with ngcc then the schematic modifies it in place removing `--first-only` and `--create-ivy-entry-points`.
ViewEngine sources under node_modules need to be updated in-place for Bazel as it does not know how to use the `__ivy__` entry points that are created by the non-bazel `ngcc` command that is added to "scripts" :`ngcc --properties es2015 browser module main --first-only --create-ivy-entry-points`.
PR Close#33435
Now that we've replaced `ngBaseDef` with an abstract directive definition, there are a lot more cases where we generate a directive definition without a selector. These changes make it so that we don't generate the `selectors` array if it's going to be empty.
PR Close#33431
The parser was accidentally reading the `target` tag
below the `alt-trans` target and overriding the correct
`target` tag.
(This already worked in `$localize` but a test has been
added to confirm.)
Fixes#33161
PR Close#33450
Prior to this commit, i18n logic which ensures that elements removed in a translation are also removed in DOM, didn't take into account the fact that elements may have local refs. As a result, remove operation failed, since there is no corresponding tNode found. This commit updates the logic to skip all local refs while going though the list of nodes to ensure that DOM matches elements present in translation.
PR Close#33415
JiaLiPassion
Pete Bacon Darwin
Alex Rickabaugh
Andrew Kushnir
Matias Niemelä
Pawel Kozlowski
crisbeto
Michael Prentice
Martin Probst
Charles Lyding
Keen Yee Liau
JoostK
Alain Chautard
Robin Dupret
NothingEverHappens
Paul Gschwendtner
Greg Magolan