We temporarily disabled the components-repo-unit-tests job as part of
a ngcc PR: #35079. This was necessary because the components repository
used postinstall patches for `@angular/compiler-cli/ngcc`. Due to
changes in ngcc, these patches no longer worked and caused the
`components-repo-unit-tests` job to fail.
The postinstall patch has been removed in the components repo, so the
job can be re-enabled.
PR Close#35123
Prior to this change, element namespace was not set for host elements of dynamically created components that resulted in incorrect rendering in a browser. This commit adds the logic to pick and set correct namespace for host element when component is created dynamically.
PR Close#35136
In Ivy's template type checker, event bindings are checked in a closure
to allow for accurate type inference of the `$event` parameter. Because
of the closure, any narrowing effects of template guards will no longer
be in effect when checking the event binding, as TypeScript assumes that
the guard outside of the closure may no longer be true once the closure
is invoked. For more information on TypeScript's Control Flow Analysis,
please refer to https://github.com/microsoft/TypeScript/issues/9998.
In Angular templates, it is known that an event binding can only be
executed when the view it occurs in is currently rendered, hence the
corresponding template guard is known to hold during the invocation of
an event handler closure. As such, it is desirable that any narrowing
effects from template guards are still in effect within the event
handler closure.
This commit tweaks the generated Type-Check Block (TCB) to repeat all
template guards within an event handler closure. This achieves the
narrowing effect of the guards even within the closure.
Fixes#35073
PR Close#35193
The `TargetedEntryPointFinder` must work out what the
containing package is for each entry-point that it finds.
The logic for doing this was flawed in the case that the
package was in a path-mapped directory and not in a
node_modules folder. This meant that secondary entry-points
were incorrectly setting their own path as the package
path, rather than the primary entry-point path.
Fixes#35188
PR Close#35227
In the past we had connecitivity issues on Saucelabs. Browsers on
mobile devices were not able to properly resolve the `localhost`
hostname through the tunnel. This is because the device resolves
`localhost` or `127.0.0.1` to the actual Saucelabs device, while it
should resolve to the tunnel host machine (in our case the CircleCI VM).
In the past, we simply disabled the failing devices and re-enabled the
devices later. At this point, the Saucelabs team claimed that the
connecitivy/proxy issues were fixed.
Saucelabs seems to have a process for VMs which ensures that requests to
`localhost` / `127.0.0.1` are properly resolved through the tunnel. This
process is not very reliable and can cause tests to fail. Related issues have been
observed/mentioned in the Saucelabs support docs. e.g.
https://support.saucelabs.com/hc/en-us/articles/115002212447-Unable-to-Reach-Application-on-localhost-for-Tests-Run-on-Safari-8-and-9-and-Edgehttps://support.saucelabs.com/hc/en-us/articles/225106887-Safari-and-Internet-Explorer-Won-t-Load-Website-When-Using-Sauce-Connect-on-Localhost
In order to ensure that requests are always resolved through the tunnel,
we add our own domain alias in the CircleCI's hosts file, and enforce that
it is always resolved through the tunnel (using the `--tunnel-domains` SC flag).
Saucelabs devices by default will never resolve this domain/hostname to the
actual local Saucelabs device.
PR Close#35171
Previously we needed the `components-repo-ci` blocklist to disable
tests that were failing during the development of Ivy. Since we fixed
all those failing tests, and we don't want to regress, we can remove the
blocklist logic.
Resolves FW-1807
PR Close#35115
Now that bazel respects the yarn-path value found in .yarnrc, we can
remove the last remaining reliances on our vendoring in
//third_party/github.com/yarnpkg/yarn/
PR Close#35083
Removing for now, since the info is stale, and we need to determine how to adjust the schedule due to the unexpected and significant version 9 delay.
PR Close#34474
A bug previously caused the template type-checking diagnostics produced by
TypeScript for template expressions to use -99-prefixed error codes. These
codes are converted to "NG" errors instead of "TS" errors during diagnostic
printing. This commit fixes the issue.
PR Close#35146
On home page, image size set to 400px, which make the page not render
properly on devices below the size of 400px width.
Also, when search results were scrolled, they interfered with the top
nav items. Added border at the top of the search results container so
that the results are not visible under the nav items during scrolling.
PR Close#35098
Footer links did not have enough space between them, so lighthouse was
reporting that tap targets are not appropriately sized. Added the
required 8px space between links.
Also updated the margin of group headers accordingly.
Fixes#34901
PR Close#35098
Because the animation completes in 2000ms, and browser.wait checks
every 100ms, there can be a race condition of if the final state has
actually been reached to read the color. By moving to 2101ms, we ensure
that we cheack after the 2000ms of the animation has completed.
PR Close#35089
- Adds `TView` into `LFrame`, read the `TView` from `LView` on `enterView`.
- Before this change the `TView` was ofter looked up from `LView` as `lView[TVIEW]`. This is suboptimal since reading from an Array, requires that the read checks array size before the read. This means that such a read has a much higher cost than reading from the property directly. By passing in the `TView` explicitly it makes the code more explicit and faster.
- Some rearrangements of arguments so that `TView` would come before `LView` for consistency.
PR Close#35069
Paul Gschwendtner