Previously, redirects had to be configured in both the Firebase config
(`firebase.json`) and the ServiceWorker config (`ngsw-config.json`).
This made it challenging to correctly configure redirects, since one had
to understand the different formats of the two configs, and was also
prone to getting out-of-sync configs.
This commit simplifies the process of adding redirects by removing the
need to update the ServiceWorker config (`ngsw-config.json`) and keep it
in sync with the Firebase config (`firebase.json`). Instead the
ServiceWorker `navigationUrls` are automatically generated from the list
of redirects in the Firebase config.
NOTE:
Currently, the automatic generation only supports the limited set of
patterns that are necessary to translate the existing redirects. It can
be made more sophisticated in the future, should the need arise.
PR Close#42452
The ServiceWorker `navigationUrls` globs defined in `ngsw-config.json`
are supposed to exclude any URLs that are redirected on the server (as
configured in `firebase.json`). However, the list of redirected
URLs/globs in `firebase.json` and `ngsw-config.json` have gotten out of
sync.
This commit updates the globs in `ngsw-config.json` to match the ones in
`firebase.json`.
This is in preparation of automatically generating the ServiceWorker
`navigationUrls` based on `firebase.json`.
PR Close#42452
This commit sorts all `navigationUrls` in `ngsw-config.json`
alphabetically.
This is in preparation of automatically generating the ServiceWorker
`navigationUrls` based on `firebase.json`.
PR Close#42452
Previously, we were not consistent in allowing a trailing `/` in
`navigationUrls` globs in `ngsw-config.json`. And when we did, we used
two globs: one with and one without the trailing `/`.
This commit updates all appropriate `navigationUrls` globs to allow a
trailing `/`. It also merges the two glob patterns (the one with and the
one without the `/`) into one.
This is in preparation of automatically generating the ServiceWorker
`navigationUrls` based on `firebase.json`.
PR Close#42452
This commit removes some `navigationUrls` globs from `ngsw-config.json`
that have no effect. More specifically:
- It removes globs of the form `!/**/xyz.html`, since these are already
covered by the more generic `!/**/*.*` glob.
- It removes `!/api/**/NgFor`, since it does not have a corresponding
redirect rule in `firebase.json`.
This is in preparation of automatically generating the ServiceWorker
`navigationUrls` based on `firebase.json`.
PR Close#42452
Previously, only sub-paths, such as `api/http/foo`, were redirected to
`guide/deprecations#http`.
This commit ensures that also `api/http` itself (which used to point to
the `http` module's API page) is redirected as well.
PR Close#42452
This commit adds a test assertion to verify that all redirect rules
defined in `firebase.json` are tested, i.e. that each rule is applied to
at least one testcase from `URLS_TO_REDIRECT.txt`.
This will ensure that any redirect rules added in the future will be
tested.
PR Close#42452
Previously, the `destinations` test suite in
`testFirebaseRedirection.spec.ts` was nested under the
`with legacy URLs` test suite. However, the two suites are unrelated and
there is no reason to have them nested.
This commit moves the `destinations` test suite to be beside (instead of
inside) the `with legacy URLs` one.
PR Close#42452
This commit adds testcases in `URLS_TO_REDIRECT.txt` for all redirect
rules defined in `firebase.json`. This ensures that all rules are tested
and work as expected.
PR Close#42452
Previously, the `NotificationComponent` would be hidden by reducing its
height to `0`. This allowed for a smoother hide animation when closing
the notification, but left the component's interactive elements
focusable via keyboard navigation. This was confusing for users, because
the focused elements would not be visible on the page.
This commit fixes the issue be also setting the `display` CSS property
to `none` when the `NotificationComponent` is hidden, thus ensuring that
its contents are not focusable via keyboard navigation.
(This does not affect the hide animation, since the `display` style is
not animatable and is only applied at the end of the animation.)
PR Close#42584
Previously, we included a dummy `MatIcon` element in `AppComponent` in
order to ensure that the `Material Icons` font would be requested (and
thus cached by the ServiceWorker) on every navigation. However, #41129
introduced the `ThemeToggleComponent`, which will be present on all
pages (since it is located in the top-menu) and relies on the
`Material Icons` font. Therefore, the work-around for loading the
`Material Icons` font is no longer necessary.
This commit removes the now redundant `MatIcon` from `AppComponent`.
PR Close#42584
This commit changes the anchor elements used for external links to
`MatIconButton`s. While the appearance remains the same (with the
exception of hover/focus styles), this better aligns the styling of
external link icons with other nearby icon buttons (i.e. the theme
toggle) and alows as to simplify the CSS for external links (since much
of their styling is handled by Angular Material).
PR Close#42584
Since we now use SVG for external link icons, there are no `<img>`
elements inside the anchor elements. So, the CSS rule does not match any
element and can be removed.
PR Close#42584
Previously, we only tracked the sizes of the eagerly loaded JS bundles.
However, the CSS styles (which also have a non-negligible size) must
also be downloaded and parsed by the browser, thus affecting the initial
rendering time.
This commit starts tracking the CSS styles payload sizes.
(Originally discussed in
https://github.com/angular/angular/pull/42584#discussion_r653787961)
PR Close#42584
The addition of overloads to some of the number pipes caused
the documentation to lose the parameter descriptions.
This change fixes that by moving the JSDOC block in from of the
primary method signature, rather than the first overload.
Fixes#42590
PR Close#42593
This reverts commit 61ad68a586135a4d7b2b920fda0cb4238c6422fe, since there
are no longer any disambiguated paths that need special handling.
PR Close#42414
To avoid having content files that have the same file path on case-insensitive
file-systems, we now encode the paths to remove uppercase characters.
PR Close#42414
This is something I ran into while working on a fix for the `TestBed` module teardown behavior for #18831. In the `RouterInitializer.appInitializer` we have a callback to the `LOCATION_INITIALIZED` which has to do some DI lookups. The problem is that if the module is destroyed before the location promise resolves, the `Injector.get` calls will fail. This is unlikely to happen in a real app, but it'll show up in unit tests once the test module teardown behavior is fixed.
PR Close#42560
We currently have two long-standing issues related to how `TestBed` tests are torn down:
1. The dynamically-created test module isn't going to be destroyed, preventing the `ngOnDestroy` hooks on providers from running and keeping the component `style` nodes in the DOM.
2. The test root elements aren't going to be removed from the DOM. Instead, they will be removed whenever another test component is created.
By themselves, these issues are easy to resolve, but given how long they've been around, there are a lot of unit tests out there that depend on the broken behavior.
These changes address the issues by introducing APIs that allow users to opt into the correct test teardown behavior either at the application level via `TestBed.initTestEnvironment` or the test suite level via `TestBed.configureTestingModule`.
At the moment, the new teardown behavior is opt-in, but the idea is that we'll eventually make it opt-out before removing the configuration altogether.
Fixes#18831.
PR Close#42566
in order to have a consistent line-height between list items containing
text and list items containing links the anchors should inherit the list
item's line-height
PR Close#42572
make sure that the width of the sidenav chervon icon is 2.4rem
(this needs to be done using the flex property and not the
width one as that can change in flex containers)
also center chevron icon inside mat-icon container in order to maintain
the correct icon positioning at any font-size
PR Close#42561
Remove the fixed height set on the card elements present in angular.io,
allowing the cards to have a dynamic height derived from their content
and thus removing overflow issues related to the browser's font-size,
make other minor css related adjustments to allow the card to look good
on the different browser's font-size settings
PR Close#42533
This commit adds support for generating pages that document
special Angular elements, such as `ng-content` and `ng-template`,
which have special behavior in Angular but are not directives nor
components.
Resolves#41273
PR Close#41299
Removes the polyfills for `MutationObserver` and `setPrototypeOf` from our testing setup, because none of the browsers that we support require them. It also removes a bit of code and one external dependency.
PR Close#42567
Previously, the "go to definition" action did no account for the
possibility that something may actually be defined in a template. This
change updates the logic in the definition builder to convert any
results that are locations in template typecheck files to their
corresponding locations in the template.
PR Close#42559
Unclosed element tags are not assigned an `endSourceSpan` by the parser.
As a result, the visitor which determines the target node at a position
for the language service was unable to determine that a given position
was inside an unclosed parent. This happens because we update the
`endSourceSpan` of template/element nodes to be the end tag (and there
is not one for unclosed tags). Consequently, the visitor then cannot
match a position to any child node location.
This change updates the visitor logic to check if there are any
`children` of a template/element node and updates the end span to be the
end span of the last child. This allows our `isWithin` logic to identify
that a child position is within the unclosed parent.
Addresses one of the issues found during investigation of https://github.com/angular/vscode-ng-language-service/issues/1399
PR Close#42554
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