Commit Graph

7681 Commits

Author SHA1 Message Date
dario-piotrowicz 0ce8f6e62d refactor(animations): remove unused animation trigger imports (#42763)
in the animation_trigger.ts file there are unused imports
remove them to clean up the file

PR Close #42763
2021-07-19 17:13:45 -07:00
dario-piotrowicz b41a2b3623 refactor(animations): remove publicApi annotations from triggers (#42763)
the buildTrigger function and AnimationTrigger class are annotated
as publicApi which seems wrong and makes changes to the two
problematic, so they are being removed here

see: https://github.com/angular/angular/pull/42763/files#r671481902

PR Close #42763
2021-07-19 17:13:45 -07:00
dario-piotrowicz f12c53342c fix(animations): normalize final styles in buildStyles (#42763)
the final styles created in buildStyles lack normalization, meaning that pixel values remain as numbers (without "px") and so such properties fail to be correctly set/applied

Example: "width: 300" is applies as "width": "300" (and thus ignored) instead of the correct "width": "300px"

PR Close #42763
2021-07-19 17:13:45 -07:00
dario-piotrowicz 5d7359e3f0 refactor(animations): fix typo in transition animations spec file (#42763)
fix the typo "mean't" in the transition_animation_engine spec file
to "meant" (the typo is simply in a code comment so the change
does not have any impact)

PR Close #42763
2021-07-19 17:13:45 -07:00
Paul Gschwendtner 3b2f607cda build: generate closure locale files using hard-coded list of locales (#42230)
With the refactoring from a Gulp task to a Bazel too, we tried switching
away from the hard-coded list of locales and aliases for the Closure
Locale file generation. After multiple attempts of landing this, it
turned out that Closure Compiler/Closure Library relies on locale
identifiers CLDR does not capture within it's `availableLocales.json`
or `aliases.json` data.

Closure Library does not use any unknown locale identifiers here. The
locale identifiers can be resolved within CLDR using the bundle lookup
algorithm that is specified as part of CLDR; instead the problem is that
the locale identifiers do not follow any reasonable pattern and
therefore it's extremely difficult to generate them automatically (it's
almost like we'd need to build up _all_ possible combinations). Instead
of doing that, we just use the hard-coded locales and aliases from the
old Closure Locale generation script.

PR Close #42230
2021-07-16 12:44:59 -07:00
Paul Gschwendtner 9d1deb16fa build: generate alias locale data for closure locale (#42230)
Within Google, closure compiler is used for dealing with translations.
We generate a closure-compatible locale file that allows for
registration within Angular, so that Closure i18n works well together
with Angular applications. Closure compiler does not limit its
locales to BCP47-canonical locale identifiers. This commit updates
the generation logic so that we also support deprecated (but aliased)
locale identifiers, or other aliases which are likely used within
Closure. We use CLDR's alias supplemental data for this. It instructs
us to alias `iw` to `he` for example. `iw` is still supported in Closure.

Note that we do not manually extract all locales supported in Closure;
instead we only support the CLDR canonical locales (as done before) +
common aliases that CLDR provides data for. We are not aware of other
locale aliases within Closure that wouldn't be part of the CLDR aliases.
If there would be, then Angular/Closure would fail accordingly.

PR Close #42230
2021-07-16 12:44:59 -07:00
Paul Gschwendtner e640db198f build: simplify generation of closure locale file (#42230)
In the past, the closure file has been generated so that all individual
locale files were imported individually. This resulted in a huge
slow-down in g3 due to the large amount of imports.

With 90bd984ff7 this changed so that we
inline the locale data for the g3 closure locale file. Also the file
only contained data for locales being supported by Closure. For this a
list of locales has been extracted from Closure Compiler, as well as a
list of locale aliases.

This logic is prone to CLDR version updates, and also broke as part of
the Gulp -> Bazel migration where this logic has been slightly modified
but caused issues in G3. e.g. a locale `zh-Hant` was requested in g3,
but the locale data had the name of the alias locale that provided the
data at index zero (which represents the locale name). Note that the
locale names at index zero always could differentiate from the requested
`goog.LOCALE` due to the aliasing logic. This just didn't come up before.

We simplify this logic by generating a `goog.LOCALE` case for all
locales CLDR provides data for. We don't need to bother about aliasing
because with the refactorings to the CLDR generation tool, all locales
are built (which also captures the aliases), and we can generate the locale
file on the fly (which has not been done before).

PR Close #42230
2021-07-16 12:44:59 -07:00
Paul Gschwendtner 87b9cebede build: add documentation for `generate-locales-tool` (#42230)
The CLDR extraction tool has been reworked to run as part of Bazel.
This adds a initial readme explaining what the tool generates. It's
far from a detailed description but it can serve as foundation for more
detailed explanations.

PR Close #42230
2021-07-16 12:44:59 -07:00
Paul Gschwendtner 444d838905 build: wire up new CLDR generation tool within Bazel (#42230)
Introduces a few Starlark macros for running the new Bazel
CLDR generation tool. Wires up the new tool so that locales
are generated properly. Also updates the existing
`closure-locale` file to match the new output generated by the Bazel tool.

This commit also re-adds a few locale files that aren't
generated by CLDR 37, but have been accidentally left in
the repository as the Gulp script never removed old locales
from previous CLDR versions. This problem is solved with the
Bazel generation of locale files, but for now we re-add these
old CLDR 33 locale files to not break developers relying on these
(even though the locale data indicies are incorrect; but there might
be users accessing the data directly)

PR Close #42230
2021-07-16 12:44:59 -07:00
Paul Gschwendtner 7a3a453072 build: convert CLDR locale extraction from Gulp to Bazel tool (#42230)
Converts the CLDR locale extraction script to a Bazel tool.
This allows us to generate locale files within Bazel, so that
locales don't need to live as sources within the repo. Also
it allows us to get rid of the legacy Gulp tooling.

The migration of the Gulp script to a Bazel tool involved the
following things:

  1. Basic conversion of the `extract.js` script to TypeScript.
     This mostly was about adding explicit types. e.g. adding `locale:
     string` or `localeData: CldrStatic`.

  2. Split-up into separate files. Instead of keeping the large
     `extract.js` file, the tool has been split into separate files.
     The logic remains the same, just that code is more readable and
     maintainable.

  3. Introduction of a new `index.ts` file that is the entry-point
     for the Bazel tool. Previously the Gulp tool just generated
     all locale files, the default locale and base currency files
     at once. The new entry-point accepts a mode to be passed as
     first process argument. based on that argument, either locales
     are generated into a specified directory, or the default locale,
     base currencies or closure file is generated.

     This allows us to generate files with a Bazel genrule where
     we simply run the tool and specify the outputs. Note: It's
     necessary to have multiple modes because files live in separate
     locations. e.g. the default locale in `@angular/core`, but the
     rest in `@angular/common`.

  4. Removal of the `cldr-data-downloader` and custom CLDR resolution
     logic. Within Bazel we cannot run a downloader using network.

     We switch this to something more Bazel idiomatic with better
     caching. For this a new repository rule is introduced that
     downloads the CLDR JSON repository and extracts it. Within
     that rule we determine the supported locales so that they
     can be used to pre-declare outputs (for the locales) within
     Bazel analysis phase. This allows us to add the generated locale
     files to a `ts_library` (which we want to have for better testing,
     and consistent JS transpilation).

     Note that the removal of `cldr-data-downloader` also requires us to
     add logic for detecting locales without data. The CLDR data
     downloader overwrote the `availableLocales.json` file with a file
     that only lists locales that CLDR provides data for. We use the
     official `availableLocales` file CLDR provides, but filter out
     locales for which no data is available. This is needed until we
     update to CLDR 39 where data is available for all such locales
     listed in `availableLocales.json`.

PR Close #42230
2021-07-16 12:44:59 -07:00
Paul Gschwendtner f2cd6de596 refactor: remove checked-in locale files (#42230)
This is a pre-refactor commit allowing us to move
the CLDR locale generation to Bazel where files would
no longer be checked-in, except for the `closure-locale`
file that is synced into Google3.

PR Close #42230
2021-07-16 12:44:58 -07:00
Renovate Bot 74228215a1 build: update dependency @microsoft/api-extractor to v7.18.4 (#42864)
PR Close #42864
2021-07-15 13:34:24 -07:00
Minko Gechev f5baa55b81 docs: remove reference to an obsolete design doc (#42842)
The type checking design document is no longer relevant. This PR
removes the reference to it. Close #42424.

PR Close #42842
2021-07-15 13:24:58 -07:00
Renovate Bot 670300e9ab build: lock file maintenance (#42824)
PR Close #42824
2021-07-15 13:22:37 -07:00
JoostK 31593db489 refactor(core): expand error logging when the JIT compiler is not available (#42693)
If a decorator or partial declaration has not been AOT compiled, then
the compiler is needed at runtime to be able to JIT compile the code.
However, it may occur that the compiler is not available, if it has not
been loaded into the application. The error that was reported in this
case did not provide insight into which class requested compilation, nor
did it differentiate between decorators vs. partial declarations.

This commit expands the error logging to provide better insight into the
class that initiated JIT compilation and offers a specialized error
message for partial declarations. This should help a developer better
understand why the error occurs and what can be done to resolve it.

Closes #40609

PR Close #42693
2021-07-15 13:19:05 -07:00
JoostK 07d7e6034f perf(compiler-cli): optimize cycle detection using a persistent cache (#41271)
For the compilation of a component, the compiler verifies that the
imports it needs to generate to reference the used directives and pipes
would not create an import cycle in the program. This requires visiting
the transitive import graphs of all directive/pipe usage in search of
the component file. The observation can be made that all directive/pipe
usages can leverage the exploration work in search of the component
file, thereby allowing sub-graphs of the import graph to be only visited
once instead of repeatedly per usage. Additionally, the transitive
imports of a file are no longer collected into a set to reduce memory
pressure.

PR Close #41271
2021-07-15 13:13:48 -07:00
JoostK cd2d82a91a fix(core): associate the NgModule scope for an overridden component (#42817)
When using `TestBed.overrideComponent`, the overridden component would
incorrectly lose access to its NgModule's declaration scope if the
NgModule had been imported into the testing NgModule as a
`ModuleWithProviders`, e.g. using a `forRoot` call.

The issue occurred as the `TestBed` compiler did not consider NgModules
that had been imported as a `ModuleWithProviders` when associating
NgModules with component overrides. This caused the overridden component
to be compiled standalone, meaning that it does not have access to
its NgModule's declarations. This commit extends the logic for
traversing the NgModule graph to also consider `ModuleWithProviders`
imports.

Fixes #42734

PR Close #42817
2021-07-13 15:59:28 -07:00
JoostK 51156f3f07 fix(core): allow proper type inference when `ngFor` is used with a `trackBy` function (#42692)
In #41995 the type of `TrackByFunction` was changed such that the
declaration of a `trackBy` function did not cause the item type to be
widened to the `trackBy`'s item type, which may be a supertype of the
iterated type. This has introduced situations where the template type
checker is now reporting errors for cases where a `trackBy` function is
no longer assignable to `TrackByFunction`.

This commit fixes the error by also including the item type `T` in
addition to the constrained type parameter `U`, allowing TypeScript to
infer an appropriate `T`.

Fixes #42609

PR Close #42692
2021-07-13 14:08:05 -07:00
Meir Blumenfeld e42aa6c13b fix(common): re-sort output of `KeyValuePipe` when `compareFn` changes (#42821)
Previously, if only the `compareFn` changed but the data itself did not, then
the `KeyValuePipe` did not re-sort the output.

Fixes #42819

PR Close #42821
2021-07-13 11:33:21 -07:00
Daniel Trevino 81dce5c664 fix(compiler-cli): check split two way binding (#42601)
Check for split two way binding when output is not declared to make error message clearer.

PR Close #42601
2021-07-13 08:47:11 -07:00
Kristiyan Kostadinov b33665ab2c fix(compiler): add mappings for all HTML entities (#42818)
Angular inserts text either through text nodes (`document.createTextNode`) or using `textContent`, but the drawback of doing so is that HTML entities won't be decoded. In order to work around it, the compiler has some logic that maps the entities to their unicode representation which can safely be inserted. The problem is that our current mapping is arbitrarily limited which means that some entities will be mapped while others will throw an error, even though they're valid.

These changes expand the list to cover all entities that are supported by the HTML spec.

Fixes #41186.

PR Close #42818
2021-07-12 14:41:20 -07:00
Paul Gschwendtner b5ab7aff43 refactor: add override keyword to members implementing abstract declarations (#42512)
In combination with the TS `noImplicitOverride` compatibility changes,
we also want to follow the best-practice of adding `override` to
members which are implemented as part of abstract classes. This
commit fixes all instances which will be flagged as part of the
custom `no-implicit-override-abstract` TSLint rule.

PR Close #42512
2021-07-12 13:11:17 -07:00
Paul Gschwendtner 1dffa51808 refactor: ensure compatibility with noImplicitOverride for examples (#42512)
Adds the `override` keyword to the `examples` sources to ensure
compatibility with `noImplicitOverride`.

PR Close #42512
2021-07-12 13:11:16 -07:00
Paul Gschwendtner 5b5868d592 refactor(zone.js): ensure compatibility with noImplicitOverride (#42512)
Adds the `override` keyword to the `zone.js` sources to ensure
compatibility with `noImplicitOverride`.

PR Close #42512
2021-07-12 13:11:16 -07:00
Paul Gschwendtner bfc4c3cf43 refactor(localize): ensure compatibility with noImplicitOverride (#42512)
Adds the `override` keyword to the `localize` sources to ensure
compatibility with `noImplicitOverride`.

PR Close #42512
2021-07-12 13:11:16 -07:00
Paul Gschwendtner 368576b045 refactor(language-service): ensure compatibility with noImplicitOverride (#42512)
Adds the `override` keyword to the `language-service` sources to ensure
compatibility with `noImplicitOverride`.

PR Close #42512
2021-07-12 13:11:16 -07:00
Paul Gschwendtner 388496c17d refactor(service-worker): ensure compatibility with noImplicitOverride (#42512)
Adds the `override` keyword to the `service-worker` sources to ensure
compatibility with `noImplicitOverride`.

PR Close #42512
2021-07-12 13:11:16 -07:00
Paul Gschwendtner 01e869a45b refactor(forms): ensure compatibility with noImplicitOverride (#42512)
Adds the `override` keyword to the `forms` sources to ensure
compatibility with `noImplicitOverride`.

PR Close #42512
2021-07-12 13:11:16 -07:00
Paul Gschwendtner c13ccc37cf refactor(elements): ensure compatibility with noImplicitOverride (#42512)
Adds the `override` keyword to the `elements` sources to ensure
compatibility with `noImplicitOverride`.

PR Close #42512
2021-07-12 13:11:16 -07:00
Paul Gschwendtner 22290af178 refactor(common): ensure compatibility with noImplicitOverride (#42512)
Adds the `override` keyword to the `common` sources to ensure
compatibility with `noImplicitOverride`.

PR Close #42512
2021-07-12 13:11:16 -07:00
Paul Gschwendtner ff87da36e7 refactor(benchpress): ensure compatibility with noImplicitOverride (#42512)
Adds the `override` keyword to the `benchpress` sources to ensure
compatibility with `noImplicitOverride`.

PR Close #42512
2021-07-12 13:11:15 -07:00
Paul Gschwendtner 634ba9ccbc refactor(upgrade): ensure compatibility with noImplicitOverride (#42512)
Adds the `override` keyword to the `upgrade` sources to ensure
compatibility with `noImplicitOverride`.

PR Close #42512
2021-07-12 13:11:15 -07:00
Paul Gschwendtner abc77a6a39 refactor(router): ensure compatibility with noImplicitOverride (#42512)
Adds the `override` keyword to the `router` sources to ensure
compatibility with `noImplicitOverride`.

PR Close #42512
2021-07-12 13:11:15 -07:00
Paul Gschwendtner 8948c93024 refactor(platform-server): ensure compatibility with noImplicitOverride (#42512)
Adds the `override` keyword to the `platform-server` sources to ensure
compatibility with `noImplicitOverride`.

PR Close #42512
2021-07-12 13:11:15 -07:00
Paul Gschwendtner 48c9a0ddc6 refactor(platform-browser-dynamic): ensure compatibility with noImplicitOverride (#42512)
Adds the `override` keyword to the `platform-browser-dynamic` sources to ensure
compatibility with `noImplicitOverride`.

PR Close #42512
2021-07-12 13:11:15 -07:00
Paul Gschwendtner a2975c7507 refactor(platform-browser): ensure compatibility with noImplicitOverride (#42512)
Adds the `override` keyword to the `platform-browser` sources to ensure
compatibility with `noImplicitOverride`.

PR Close #42512
2021-07-12 13:11:15 -07:00
Paul Gschwendtner c74927da37 refactor(core): ensure compatibility with noImplicitOverride (#42512)
Adds the `override` keyword to the `core` sources to ensure
compatibility with `noImplicitOverride`.

PR Close #42512
2021-07-12 13:11:15 -07:00
Paul Gschwendtner 73137563d5 refactor(animations): ensure compatibility with noImplicitOverride (#42512)
Adds the `override` keyword to the `animations` sources to ensure
 compatibility with `noImplicitOverride`.

PR Close #42512
2021-07-12 13:11:15 -07:00
Paul Gschwendtner ccbb913f4b refactor(compiler-cli): ensure compatibility with noImplicitOverride (#42512)
Adds the `override` keyword to the `compiler-cli` sources to ensure
compatibility with `noImplicitOverride`.

PR Close #42512
2021-07-12 13:11:14 -07:00
Paul Gschwendtner 96c93260a2 refactor(compiler): ensure compatibility with noImplicitOverride (#42512)
Adds the `override` keyword to the `compiler` sources to ensure
compatibility with `noImplicitOverride`.

PR Close #42512
2021-07-12 13:11:14 -07:00
Paul Gschwendtner c7d20639c6 build: enable noImplicitOverride in project (#42512)
Enables the `noImplicitOverride` option to improve
overall codehealth in the repository.

PR Close #42512
2021-07-12 13:11:14 -07:00
Arthur Ming e8be045cbd refactor(core): optimize the implementation about finding context from error in ErrorHandler (#42581)
in _findContext method, use conditional operator check whether the params 'error' exists and then us reccursion way to find context in original error  if getDebugContext's result does not exist.

PR Close #42581
2021-07-12 12:00:19 -07:00
Arthur Ming 1067be7ab8 build: update all symbol extractor (#42581)
update all symbol extractor by running 'yarn symbol-extractor:update' script

PR Close #42581
2021-07-12 12:00:19 -07:00
Arthur Ming 1e2d879632 refactor(core): optimize the implementation about finding context from error in ErrorHandler (#42581)
in _findContext method, use conditional operator  check whether the params 'error' exists and then use nullish coalescing operator instead conditional operator when getDebugContext's result does not exist.

PR Close #42581
2021-07-12 12:00:19 -07:00
Kristiyan Kostadinov 404c8d0d88 fix(compiler): incorrect context object being referenced from listener instructions inside embedded views (#42755)
Currently unless a listener inside of an embedded view tries to reference something from the parent view, or if the reference is a local ref, we don't generate the view restoration instructions and we allow for the value to be picked up from the context object in the function parameters. The problem is that the listener is only run during creation mode and the context object may have been swapped out afterwards.

These changes fix the issue by always generating the view restoration instructions for listeners inside templates.

Fixes #42698.

PR Close #42755
2021-07-12 11:58:18 -07:00
JoostK 4c482bf3f1 fix(compiler-cli): properly emit literal types when recreating type parameters in a different file (#42761)
In #42492 the template type checker became capable of replicating a
wider range of generic type parameters for use in template type-check
files. Any literal types within a type parameter would however emit
invalid code, as TypeScript was emitting the literals using the text as
extracted from the template type-check file instead of the original
source file where the type node was taken from.

This commit works around the issue by cloning any literal types and
marking them as synthetic, signalling to TypeScript that the literal
text has to be extracted from the node itself instead from the source
file.

This commit also excludes `import()` type nodes from being supported,
as their module specifier may potentially need to be rewritten.

Fixes #42667

PR Close #42761
2021-07-12 11:48:34 -07:00
behrooz bozorg chami 40da386a4d docs(core): fix `ViewChildren` code examples to avoid TS error (#42816)
Add a non-null assertion (`!`) in `ViewChildren` code examples to avoid
a TypeScript error due to uninitialized property.

Fixes #42811

PR Close #42816
2021-07-12 09:48:30 -07:00
Paul Gschwendtner 762e057e85 build: update to rules_nodejs v4.0.0-beta.0 (#42760)
Updates the Bazel NodeJS rules to v4.0.0-beta.0. This is necessary
so that the Angular components repo can update, and it's generally
good to stay as up-to-date as possible with the Bazel rules as it's
easy to fall behind, and updating early allows us to discover issues
affecting our tooling earlier (where they are easier to address due to
e.g. potential breaking change policy).

PR Close #42760
2021-07-09 14:50:15 -07:00
Paul Gschwendtner 9da68a77e6 refactor(bazel): compatibility with `rules_nodejs` v4.0.0 (#42760)
This commit applies changes to `@angular/bazel` which are necessary
to support the Bazel NodeJS rules v4.0.0. The Bazel NodeJS rules
no longer support the `_tslibrary` option for the `LinkablePackageInfo`
provider and therefore we need to stop using it. Due to this removal,
we also need to add two new attributes called `package_name` and
`package_path` so that the API of `ng_module` matches `ts_library`.

Note: This is denoted as `refactor` as we currently are not able to
merge feature commits into patch branches, but we want the tooling
to not diverge significantly between the patch and next branch. It is
planned to update the merge tooling to allow for such changes to land.

PR Close #42760
2021-07-09 14:50:15 -07:00
Paul Gschwendtner 12443ea739 build: remove `skydoc` and `rules_sass` from repository (#42760)
Skydoc is no longer used as `@angular/bazel` is no longer a
public API. The Sass rules were only used in a single place
in the repo where Sass is not really needed and has just been
added by accident most likely. We want to remove the Sass dependency
in preparation for Rules NodeJS v4.x where the Sass rules currently
still use an older version of `@bazel/worker` that is incompatible.

PR Close #42760
2021-07-09 14:50:15 -07:00