Fixes that the runtime was throwing a DI error when attempting to inject a missing `useExisting` provider, despite the call being optional.
The problem was that when the provider has `useExisting`, we do a second `inject` call under the hood which didn't include the inject flags from the original call.
Fixes#61121.
PR Close#61137
Other code may depend on `ngServerMode` and it might have been set
globally / via a bundler. Forcing it to `undefined` in those situations
can lead to hard debug issues where the only symptom is that "suddenly"
browser-specific code paths run on the server and (obviously) break.
PR Close#61106
Fixes that the template binder didn't resolve references to DOM nodes (e.g. `<div #ref></div>` if the matcher being passed in isn't a `SelectorMatcher`.
PR Close#61100
Fixes that we weren't emitting references to selectorless pipes, because we were checking the name of the pipe, rather than the local name of the symbol.
PR Close#61100
These changes connect the dependency analysis data from the previous commits with the template type checker which allows us to fully type check a selectorless component.
Also includes tests for all of the new selectorless behaviors that have been introduced so far.
PR Close#61100
This commit removes the use of the privately exported
PendingTasksInternal everywhere except for Router. A follow-up change
will be done to remove that one as well and delete the private export.
PR Close#61049
There is nothing in the Router that requires ZoneJS and we do not need
`fakeAsync` as a mock clock. We can instead use any mock clock implementation
to speed up test execution.
This removes ZoneJS completely from the bundle of the Router tests.
ZoneJS causes the stacks to be unreadable when combined with the massive
rxjs stack in the router transition.
PR Close#61078
The `ts_project` interop rule that we've built was also used in the
Angular CLI migration, and it allows us to mix `ts_project` and
`ts_library` targets; enabling an incremental migration. Additionally
set up the `ng_project` to replace `ng_module`.
PR Close#61087
This is necessary for an incremental migration to `rules_js` which
requires Bazel v6. Bazel v6 removed the managed directories feature,
which means we no longer can rely on symlinked node modules as the Bazel
repository; but rather need to duplicate dependencies. This is
okay/acceptable to enable the incremental migration.
PR Close#61087
According to the promise specification, promises are not cancellable by default.
Once a promise is created, it will either resolve or reject, and it doesn't
provide a built-in mechanism to cancel it.
There may be situations where a promise is provided, and it either resolves after
the pipe has been destroyed or never resolves at all. If the promise never
resolves — potentially due to factors beyond our control, such as third-party
libraries — this can lead to a memory leak.
When we use `async.then(updateLatestValue)`, the engine captures a reference to the
`updateLatestValue` function. This allows the promise to invoke that function when it
resolves. In this case, the promise directly captures a reference to the
`updateLatestValue` function. If the promise resolves later, it retains a reference
to the original `updateLatestValue`, meaning that even if the context where
`updateLatestValue` was defined has been destroyed, the function reference remains in memory.
This can lead to memory leaks if `updateLatestValue` is no longer needed or if it holds
onto resources that should be released.
When we do `async.then(v => ...)` the promise captures a reference to the lambda
function (the arrow function).
When we assign `updateLatestValue = null` within the context of an `unsubscribe` function,
we're changing the reference of `updateLatestValue` in the current scope to `null`.
The lambda will no longer have access to it after the assignment, effectively
preventing any further calls to the original function and allowing it to be garbage collected.
If Chrome is built with additional flags and run with `--allow-natives-syntax --track-retaining-path`,
we could use `%DebugTrackRetainingPath` to see the distance from the root for `updateLatestValue`
if it's passed directly to async.then, e.g.:
```js
%DebugTrackRetainingPath(updateLatestValue);
// Distance from root 4: 0x123456789abc <JSPromise (sfi = 0x1fbb02e2d7f1)>
```
PR Close#58041
Miles Malerba