Presumably, the size of the results array was checked so that a TS
source file wouldn't have to be created if there were no diagnostics.
However, it is very likely that a TS program already has the
`ts.SourceFile` for file when diagnostics are queried. This removal is
just to make the function a minimal amount simpler.
PR Close#32587
This patch is a final major refactor in styling Angular.
This PR includes three main fixes:
All temporary state taht is persisted between template style/class application
and style/class application in host bindings is now removed.
Removes the styling() and stylingApply() instructions.
Introduces a "direct apply" mode that is used apply prop-based
style/class in the event that there are no map-based bindings as
well as property collisions.
PR Close#32259
PR Close#32596
Previously, the docker images used on CI where specified by a tag
(`10.16` and `10.16-browsers`). Since tags are not immutable, this only
pins specific characteristics of the environment (e.g. the OS type and
the Node.js version), but not others. Especially when using a tag that
does not specify the patch version (e.g. `10.16` instead of `10.16.0`),
it is inevitable that the image will change at some point, potentially
leading to unrelated failures due to changes in the environment.
One source of such failures can be the Chrome version used in tests.
Since we install a specific ChromeDriver version (that is only
compatible with specific Chrome version ranges), unexpectedly updating
to a newer Chrome version may break the tests if the new version falls
outside the range of supported version for our pinned ChromeDriver.
Using a tag that specifies the patch version (e.g. `10.16.0`) or even
the OS version (e.g. `10.16.0-buster`) is safer (i.e. has a lower
probability of introducing the kind of breakages described above), but
is still not fully hermetic.
This commit prevents such breakages by pinning the docker images by ID.
Image IDs are based on the image's digest (SHA256) and are thus
immutable, ensuring that all CI jobs will be running on the exact same
image.
See [here][1] for more info on pre-built CircleCI docker images and more
specifically [pinning images by ID][2].
[1]: https://circleci.com/docs/2.0/circleci-images
[2]: https://circleci.com/docs/2.0/circleci-images#using-a-docker-image-id-to-pin-an-image-to-a-fixed-version
PR Close#32602
This PR modifies the `expanding_rows` test so that it works in g3.
1. `index,ts` must be named `index_aot.ts`
2. Scripts should be loaded via `ts_devserver` and not as an explicit
script tag in the HTML.
PR Close#32568
This commit expands the `lint` CircleCI job to also run the
`tools/verify-codeownership.js` script. This script verifies that some
important files/directories in the codebase have code-owners assigned in
`.github/CODEOWNERS`.
The main purpose of this change is to prevent adding new directories
(e.g. packages or docs guides/examples) without assigning appropriate
code-owners. When no code-owner is explicitly assigned, corresponding
PRs will automatically request reviews from @igorminar, who is the
"fall-back" code-owner.
PR Close#32577
The `aio/scripts/verify-codeownership.js` script (formerly
`verify-docs-codeownership.js`) can be used to verify whether there are
directories in the codebase that don't have a codeowner (in
`.github/CODEOWNERS`) and vice versa. It does not aim to cover all files
and directories, but do a coarse check on some important (or frequently
changing) directories.
Previously, the script only checked for API docs examples (in
`packages/examples/`) and guides (and related images and example) (in
`aio/content/`).
This commit expands the script to also check for packages (i.e.
top-level directories in `packages/`). It also renames the script from
`verify-docs-codeownership.js` to `verify-codeownership.js`, to better
reflect its new behavior.
PR Close#32577
This patch is a final major refactor in styling Angular.
This PR includes three main fixes:
All temporary state taht is persisted between template style/class application
and style/class application in host bindings is now removed.
Removes the styling() and stylingApply() instructions.
Introduces a "direct apply" mode that is used apply prop-based
style/class in the event that there are no map-based bindings as
well as property collisions.
PR Close#32259
Follow-up for de8ebbdfd0. We need to
disable a few HammerJS gesture tests of the component repository by
adding them to the material-ci test blocklist.
This is now surfaces because we updated the commit of the
`material-unit-tests` job to a more recent state where we re-enabled
the HammerJS gesture tests on the components-side. The tests were
previously disabled on the components repository because the blocklist
didn't work on Angular. See:
eaf70ca2a0.
PR Close#32485
Ensures that the `material-unit-tests` job does not accidentally build
subpackages of the `src/dev-app` in the components repo. This is now
an issue because the components repository updated their dev-app
to use Bazel with more individual subpackages. These subpackages
are not excluded by the `--deleted_packages` flag.
For best practice, we should use the exclusion target pattern
instead of the undocumented `--deleted_packages` flag anyway.
PR Close#32485
Updates the SHA that will be tested against in the `material-unit-tests` job
to the latest commit in the components repository. SHA 2817c9e2faa4140342336987a692d5dd30bf24c2
is needed in order to make the `material-unit-tests` job pass after the remove
of the `protractor_web_test_suite` bazel rule from @angular/bazel. `protractor_web_test_suite` is
now provided by the @bazel/protractor npm package.
PR Close#32485
BREAKING CHANGE:
Angular bazel users using protractor_web_test_suite from @angular/bazel npm package should now switch to the @bazel/protractor npm package.
This should impact very few users and the user's that are impacted have a very easy upgrade path to switch to fetching the protractor_web_test_suite rule via the @bazel/protractor npm package.
PR Close#32485
This PR fixes a critical performance issue where the language
service makes a MASSIVE number of filesystem calls when performing
module resolution.
This is because there is no caching. To make matters worse, module
resolution is performed for **every** program change (which means every
few keystrokes trigger a massive number of fs calls).
PR Close#32479
Prior to this commit, a directive with a selector `selector=".Titledir"` would not match an element like `div class="titleDir"` in Ivy whereas it would in VE. The same issue was present for `selector="[title=Titledir]` and `title="titleDir"`. This fixes the Ivy behavior by changing the matching algorithm to use lowercased values.
Note that some `render3` tests needed to be changed to reflect that the compiler generates lowercase selectors. These tests are in the process to be migrated to `acceptance` to use `TestBed` in another PR anyway.
PR Close#32548
Adds two acceptance tests to show a current difference in behavior between Ivy and VE.
A directive with a selector `.Titledir` matches an element with `class="titleDir"` in VE but not in Ivy.
Same thing for an attribute value.
PR Close#32548
Prior to this commit, the `previousOrParentTNode` was set to null after performing all operations within `refreshView` function. It's causing problems in more complex scenarios, for example when change detection is triggered during DI (see test added as a part of this commit). As a result, global state might be corrupted. This commit captures current value of `previousOrParentTNode` and restores it after `refreshView` call.
PR Close#32521
Replaces the `select` instruction with a new one called `advance`. Instead of the jumping to a specific index, the new instruction goes forward X amount of elements. The advantage of doing this is that it should generate code the compresses better.
PR Close#32516
The `goog.getMsg()` function requires placeholder names to be camelCased.
This is not the case for `$localize`. Here placeholder names need
match what is serialized to translation files.
Specifically such placeholder names keep their casing but have all characters
that are not in `a-z`, `A-Z`, `0-9` and `_` converted to `_`.
PR Close#32509
Prior to this change, the template source mapping details were always
built during the analysis phase, under the assumption that pre-analysed
templates would always correspond with external templates. This has
turned out to be a false assumption, as inline templates are also
pre-analyzed to be able to preload any stylesheets included in the
template.
This commit fixes the bug by capturing the template source mapping
details at the moment the template is parsed, which is either during the
preanalysis phase when preloading is available, or during the analysis
phase when preloading is not supported.
Tests have been added to exercise the template error mapping in
asynchronous compilations where preloading is enabled, similar to how
the CLI performs compilations.
Fixes#32538
PR Close#32544
Adds support for `styleUrls` definitions in the same way `templateUrl`
definitions are provided; clicking on styleUrl will take a user to the
respective file.
Unifies some code in determining a URL definition. We first check if a
url is a `templateUrl`; if it's not, we check that it's a `styleUrl` or
return no definitions.
PR Close#32464
This gives an overview of how much time is spent in each operation/phase
and makes it easy to do rough comparisons of how different
configurations or changes affect performance.
PR Close#32427
`ngcc` supports both synchronous and asynchronous execution. The default
mode when using `ngcc` programmatically (which is how `@angular/cli` is
using it) is synchronous. When running `ngcc` from the command line
(i.e. via the `ivy-ngcc` script), it runs in async mode.
Previously, the work would be executed in the same way in both modes.
This commit improves the performance of `ngcc` in async mode by
processing tasks in parallel on multiple processes. It uses the Node.js
built-in [`cluster` module](https://nodejs.org/api/cluster.html) to
launch a cluster of Node.js processes and take advantage of multi-core
systems.
Preliminary comparisons indicate a 1.8x to 2.6x speed improvement when
processing the angular.io app (apparently depending on the OS, number of
available cores, system load, etc.). Further investigation is needed to
better understand these numbers and identify potential areas of
improvement.
Inspired by/Based on @alxhub's prototype: alxhub/angular@cb631bdb1
Original design doc: https://hackmd.io/uYG9CJrFQZ-6FtKqpnYJAA?view
Jira issue: [FW-1460](https://angular-team.atlassian.net/browse/FW-1460)
PR Close#32427
Kara Erickson
ayazhafiz
Judy Bogart
crisbeto
Andrius
Matias Niemelä
George Kalpakas
Keen Yee Liau
idzark
Paul Gschwendtner
Greg Magolan
Andrew Scott
Pawel Kozlowski
Kapunahele Wong
Pete Bacon Darwin
Tom Kwong
cexbrayat
Trevor Karjanis
Keen Yee Liau
Andrew Kushnir
Phaneendra
Carlos Ortiz García
JoostK
Leonardo Zizzamia
lazarljubenovic