This commit updates the parser logic to continue to try to match an end
tag to an unclosed open tag on the stack. Previously, it would only
push an error to the list and stop looking at unclosed elements.
For example, the invalid HTML of `<li><div></li>`, has an unclosed
element stack of [`li`, `div`] when it encounters the close `li` tag.
We compare against the previously unclosed tag `div` and see that this is
unexpected. Instead of simply giving up here, we continue to move up the
unclosed tags until we find a match (if there is one).
PR Close#42554
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
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
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
Given that the locale files are now generated through
Bazel, the files are no longer checked-in and the
legacy TSC compilation fails due to imports resolving
to non-existent files. We fix this for the legacy
saucelabs job by copying the generated TS files into
the sources (which is acceptable for the isolated CI job)
PR Close#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
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
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
When a FormControl, FormArray, or FormGroup is first constructed, if an async validator is attached, the `statusChanges` observable should receive a message when the validator complete (i.e. pending -> valid/invalid). If the validator was provided as part of the constructor options, it was not fired at construction time, which is fixed in this PR.
Fixes#35309.
PR Close#42553
Previously, due to a bug in Firebase hosting, requests to
`/index.html?<query>` would lead to an infinite redirect and eventually
a failure. This affected, for example, cache-busting requests from the
ServiceWorker, which look like: `/index.html?ngsw-cache-bust=...`
For more details see
https://github.com/angular/angular/issues/42518#issuecomment-858545483
This commit temporarily works around the bug by explicitly redirecting
`/index.html?<query>` to `/?<query>`.
Fixes#42518
PR Close#42547
This commit adds a popup to angular.io to inform the user about the use
of cookies. Once the user confirms having read the info, the popup will
not be shown on subsequent visits.
This commit is partly based on angular/material.angular.io#988.
Fixes#42209
PR Close#42259
Previously, we had the same logic in a couple of places to safely access
the `Window`'s `local-/sessionStorage` and provide a no-op fallback if
necessary. Soon, we will need the same logic for the cookies popup
(see #42209).
This commit reduces code duplication by providing
`local-/sessionStorage` as injectables and sharing the logic for
accessing them safely. This also makes it easier to mock the storage in
tests without having to mess with the actual `Window` object.
NOTE:
This commit actually decreases the payload size in the `main` bundle by
40B.
PR Close#42259
due to unknown `<mat-icon>` element
This commit fixes some warnings in the unit tests of the
`ThemeToggleComponent`, which were caused by the following:
- The `<mat-icon>` element used in `ToggleThemeComponent`'s template was
not declared in tests.
- The `dark-theme.css` and `light-theme.css` files requested by
`ToggleThemeComponent` were not available.
PR Close#42259
This commit aligns the angular.io config files more closely to how a
newly generated CLI v12 app would look like. This helps validate the
setup and makes it easier to apply new chages in the future (by
preventing the angular.io layout from deviating too much from the
default new app layout).
PR Close#42259
The approach for tables is more of an ad-hoc determination based on the
complexity of what's in them. If/when we enable formatting of markdown
files, that will also make the markdown format of tables easier to read
and more consistent.
fixes#23978
PR Close#42330
We can’t determine whether the user actually meant the `back` or
the `forward` using the popstate event (triggered by a browser
back/forward)
so we instead need to store information on the state and compute the
distance the user is traveling withing the browser history.
So by using the `History#go` method,
we can bring the user back to the page where he is supposed to be after
performing the action.
implementation for #13586
PR Close#38884
Close#41867
In the previous commit https://github.com/angular/angular/pull/41562#issuecomment-822696973,
the error thrown in the event listener will be caught and re-thrown, but there is a bug
in the commit, if there is only one listener for the specified event name, the error
will not be re-thrown, so this commit fixes the issue and make sure the error is re-thrown.
PR Close#41868
With this change we remove polyfills that are listed in suggested/mandatory but are not needed by Angular CLI users, since the Angular CLI will include these polyfills by default.
Closes#39793
PR Close#42263
In watch builds, the compiler attempts to reuse as much information from
a prior compilation as possible. To accomplish this, it keeps a
reference to the most recently succeeded `TraitCompiler`, which contains
all analysis data for the program. However, `TraitCompiler` has an
internal reference to an `IncrementalBuild`, which is itself built on
top of its prior state. Consequently, all prior compilations continued
to be referenced, preventing garbage collection from cleaning up these
instances.
This commit changes the `AnalyzedIncrementalState` to no longer retain
a `TraitCompiler` instance, but only the analysis data it contains. This
breaks the retainer path to the prior incremental state, allowing it to
be garbage collected.
PR Close#42537
Previously the autoRegisterModuleById registration was marked with noSideEffects wrapper to ensure that we don't end up retaining all NgModules.
However the return value was not referenced by anything, so closure compiler removed it because it determined that this code has no side effects and is not referenced by anyone.
This issue affects apps that use Closure Compiler and also rely on https://angular.io/api/core/getModuleFactory to retrieve factories by ID. This combination is used heavily in google3, especially in Pantheon.
Fixes b/188453434
PR Close#42529
`onSameUrlNavigation` only affects whether the Angular Router
processes the URL and runs it through the navigation pipeline,
retriggering redirects, guards, and resolvers. The name `reload` is a
little confusing because it does _not_ reload the component. Developers
_also_ need to implement a custom `RouteReuseStrategy` to trigger a
component reload on same URL navigation.
Fixes#21115
PR Close#42275
As previously discussed in pull/31070 and issues/30486, this would be useful because it is often desirable to apply styles to fields that are both `ng-invalid` and `ng-pristine` after the first attempt at form submission, but Angular does not provide any simple way to do this (although evidently Angularjs did). This will now be possible with a descendant selector such as `.ng-submitted .ng-invalid`.
In this implementation, the directive that sets control status classes on forms and formGroups has its set of statuses widened to include `ng-submitted`. Then, in the event that `is('submitted')` is invoked, the `submitted` property of the control container is returned iff it exists. This is preferred over checking whether the container is a `Form` or `FormGroup` directly to avoid reflecting on those classes.
Closes#30486.
PR Close#42132.
This reverts commit 00b1444d12, undoing the rollback of this change.
PR Close#42132
A subsequent commit is going to change disambiguated URLs.
This commit prepares the AIO application to attempt the new URLs
if the old URLs fail. This will help to mitigate problems that may occur
during the period between deployment of the new version and the
service-worker not being updated.
PR Close#42509
Andrew Scott
Paul Gschwendtner
Ankit Choudhary
Dylan Hunn
George Kalpakas
Mladen Jakovljević
Ahmed Ayed
Renovate Bot
Pete Bacon Darwin
gobika21
Pham Huu Hien
Aristeidis Bampakos
Kapunahele Wong
JiaLiPassion
Alan Agius
JoostK
Igor Minar
Jessica Janiuk
David Shevitz
Teri Glover
kuncevic
Santosh Yadav
Sam Severance
anups1
Chris
Tiago Temporin