With the recent lock file maintenance, the `@types/angular` dependency
ended up being duplicated. This seems to happen because we locked our
type dependency, but other Angular deps like `angular-route` had a
looser dependency, resulting in e.g. `1.7` types and `1.8` types to be
loaded.
This ultimately ended up breaking TypeScript's auto-discovering
of types and broke some example compilations e.g.
```
app/app.animations.ts(3,3): error TS2339: Property 'animation' does not exist on type 'IModule'.
app/app.config.ts(5,45): error TS2694: Namespace 'angular' has no exported member 'route'.
app/phone-detail/phone-detail.component.ajs.ts(10,37): error TS2694: Namespace 'angular' has no exported member 'route'.
```
We fix this by loosening the type dependency ranges, updating all of
these. Also we update AngularJS itself to the final version.
PR Close#46819
The AIO payload size has been reduced with lock file maintenance which
resulted in updates of Angular framework and Angular devkit/CLI.
The same reduction is already visible in the `aio-local` job because
it was already using the latest FW packages (obviously -- given it being
from HEAD).
PR Close#46819
move the check for non-animatable properties from the animation building
phase to the application of the animation's transition instead, in such
a way we can check it against the keyframes of the transition's timeline
in order to only provide warnings for properties which are being
animated, thus not providing any warning for non-animatable properties
being applied to elements via the style function
this change has the benfit just mentioned above but it comes with two
drawbacks:
- the warning handling is not done in the building time so it is a bit
inconsistent with other type of validations (such as the unsupported css
properties one for example)
- before the warning was being applied only when the animation's data
was being parsed, so it happed only once but now since it is applied
when the animation is actually being prepared to be played, it happens
each time the animation runs
resolves#46602
PR Close#46666
After a bugfix in #46096, the compiler is now better capable of detecting pipes
which require an inline type constructor. However, there is an issue in how all
pipes are considered when verifying the inline type-ctor requirement: it should
only check actually used pipes.
Fixes#46747
PR Close#46807
The JS size-tracking logic has been moved into the dev-infra repository
and the rule has been updated to work better with Bazel labels. The
Starlark target is updated accordingly in this commit.
PR Close#46802
This commit adds the following functions to the public API:
- provideAnimations
- provideNoopAnimations
The goal of those functions is to return a set of providers required to setup animations in an application. The functions are useful when the `bootstrapApplication` function is used to bootstrap an app. The functions allow to avoid the need to import `BrowserAnimationsModule` and `BrowserNoopAnimationsModule` NgModules.
PR Close#46793
This commit adds an extended diagnostics check that is similar to the nullish
coalescing check, but targeting optional chains. If the receiver expression
of the optional chain is non-nullable, then the extended diagnostic can report
an error or warning that can be fixed by changing the optional chain into a
regular access.
Closes#44870
PR Close#46686
This commit adds the `createNgModuleRef` function alias to the public API. The alias is called `createNgModule`. The `createNgModule` name is more consistent with the rest of the API surface, where functions that return `*Ref`s don't include the `Ref` into the function name, for example: `createPlatform`, `ViewContainerRef.createComponent`, etc.
DEPRECATED:
The `createNgModuleRef` is deprecated in favor of newly added `createNgModule` one.
PR Close#46789
This script was used back when dev-infra code was part of
the Angular framework repository. The script is now unused
and can be deleted.
PR Close#46798
The jasmine seed generator is only used in a single karma configuration
file. Used by the legacy build and the Saucelabs/ZoneJS Karma jobs.
We should move the separate script code directly into the config to make
it clear that the seed generation is not used elsewhere, and to simplify
the Starlark code.
PR Close#46798
Most of the increase comes from code being moved from `index.html`
to the main bundle. A small increase comes from the additional `gtag.js`
loading logic, but other than that the size is effectively increased
due to the untracked code from `index.html` being moved into the
`main.js` bundle.
PR Close#46716
This is acceptable because `gtag.js` is also only loaded as part of the
service, similary `ga` is only registered in the service (so the
reporting was a noop if errors are thrown before -- no change here)
We can benefit from downleveling etc. and do not need to be careful
with the inline script in the `index.html`
PR Close#46716
We currently use Universal Analytics. This is deprecated in favor of
Google Analytics 4 and UA will stop processing hits in October 2023.
This change intends to prepare us for this migration, and to already
pre-populate our GA4 property (there is no way to migrate existing data
/properties into a GA4 property -- a new one needs to be created).
This will help us minimize the data gap so that we can:
* Continue to look at the UA property with the full time span until
October 2023
* Can start using the GA4 property long-term in the future, starting
with data even before Universal Analytics stops processing new data.
We need to keep the existing `analytics.js` setup. Initially we have
considered using `gtag.js` for both the UA and GA4 properties, as it
supports that, but that doesn't work with our strict trusted types
enforcement because it results in multiple `gtag.js` scripts (specific
versions for UA or GA4) that recreate the same trusted type policies.
This causes runtime errors and breaks the setup.
Instead, with continued use of `analytics.js` we have the benefit of
a good separation of trusted types + events and configuration. There is
some problematic with translation of Universal Analytics Events to GA4,
or the other way around (even though we don't use custom events
currenlty)
We also do not need to send page views for our GA4 property because GA4
with gtag supports this automatically (respecting the history state --
using the `Enhanced measurement events` setting in the UI).
For our UA legacy instance we continue to dispatch events manually. This
logic can be removed in the future.
More details can be found here:
https://docs.google.com/document/d/1aK8u4ZlXbqQ2wMqmgSX7Ces8iLgamC13oCoG6VeBruA/edit?usp=sharing&resourcekey=0-EVe-Rhnme3bj_pkz2RcOmw.
PR Close#46716
Remove or reframe references to the obsolete HeroListComponent component that was taken from an old version of the Tour of Heroes tutorial.
Incorporates review feedback.
Fix#44662
PR Close#46647
The integration test rule now always executes tests in a directory
outside of the execroot. This ensures a more hermetic test environment
on platforms without a sandbox, or when tests are run with `tags:
local`.
As part of this change, an issue with Yarn 1.x. and `nodejs_binary`
unveiled. Yarn 1.x. is resolved properly using the tool mapping but
when Yarn inside Yarn is invoked (e.g. using `package.json` scripts),
then the second nested Yarn invocation fails due to an unknown path.
This happens because Yarn in the original invocation creates another
directory in the `/tmp` directory and modifies the `PATH` so that
the same `yarn` can be invoked again. This makes sense conceptually
but breaks in our case because the Yarn Bash script put into the `/tmp`
directory tries to resolve our vendored Yarn script relatively (which
is the wrong spot here). It worked previously in the execroot because
`nodejs_binary` invoked Yarn through `<external>/../node.sh
<absolute-path-to-yarn-cjs-script>`, but outside the execroot it invoked
Yarn using a relative path (which then ended up being preserved in the
Yarn temporary directory).
We can fix this by updating the Bazel NodeJS repository which seems to
have coincidentally have a fix for the path resolution. See:
https://github.com/bazelbuild/rules_nodejs/pull/3493#event-6870301735.
PR Close#46778
Import `AsyncStackTaggingZoneSpec` if the user imported
`zone.js/plugins/async-stack-tagging` bundle. So the user can
use `console.trace` to output the `async task` information more
clearly.
PR Close#46693
Chrome has an experimental API to improve the debug experience of the
async tasks.
The details can be found here https://bugs.chromium.org/p/chromium/issues/detail?id=332624#c29
This commit add the `async stack tagging` support in the `zone.js`.
User can `import 'zone.js/plugins/async-stack-tagging';` to enable this
feature.
PR Close#46693
Before this commit, the `NavigationCancellationCode` would always be set
to `Redirect` when encountering a "navigationcancelingError". However,
this error can also be thrown when `CanLoad` guars reject. This commit
ensures these cancellation errors have a code as well so this mistake
cannot be made again.
PR Close#46752
The existing logic does something similar but in a more roundabout way.
It reads _the whole array_. If it encounters a pending value, it ignores
the remaining ones. If it hasn't encountered a pending value by the time
it hits false/UrlTree, it returns that result.
The new logic is the same, but reverses what we're looking for. Instead
of processing the whole array, we stop when we encounter an initial
value. When we encounter one that isn't `true`, that gets returned. If
we get to the end and everything was `true`, return `true`.
PR Close#46745
PR Close#46745
Jessica Janiuk