in _findContext method, use conditional operator check whether the params 'error' exists and then us reccursion way to find context in original error if getDebugContext's result does not exist.
PR Close#42581
in _findContext method, use conditional operator check whether the params 'error' exists and then use nullish coalescing operator instead conditional operator when getDebugContext's result does not exist.
PR Close#42581
Currently unless a listener inside of an embedded view tries to reference something from the parent view, or if the reference is a local ref, we don't generate the view restoration instructions and we allow for the value to be picked up from the context object in the function parameters. The problem is that the listener is only run during creation mode and the context object may have been swapped out afterwards.
These changes fix the issue by always generating the view restoration instructions for listeners inside templates.
Fixes#42698.
PR Close#42755
In #42492 the template type checker became capable of replicating a
wider range of generic type parameters for use in template type-check
files. Any literal types within a type parameter would however emit
invalid code, as TypeScript was emitting the literals using the text as
extracted from the template type-check file instead of the original
source file where the type node was taken from.
This commit works around the issue by cloning any literal types and
marking them as synthetic, signalling to TypeScript that the literal
text has to be extracted from the node itself instead from the source
file.
This commit also excludes `import()` type nodes from being supported,
as their module specifier may potentially need to be rewritten.
Fixes#42667
PR Close#42761
Updates the Bazel NodeJS rules to v4.0.0-beta.0. This is necessary
so that the Angular components repo can update, and it's generally
good to stay as up-to-date as possible with the Bazel rules as it's
easy to fall behind, and updating early allows us to discover issues
affecting our tooling earlier (where they are easier to address due to
e.g. potential breaking change policy).
PR Close#42760
This commit applies changes to `@angular/bazel` which are necessary
to support the Bazel NodeJS rules v4.0.0. The Bazel NodeJS rules
no longer support the `_tslibrary` option for the `LinkablePackageInfo`
provider and therefore we need to stop using it. Due to this removal,
we also need to add two new attributes called `package_name` and
`package_path` so that the API of `ng_module` matches `ts_library`.
Note: This is denoted as `refactor` as we currently are not able to
merge feature commits into patch branches, but we want the tooling
to not diverge significantly between the patch and next branch. It is
planned to update the merge tooling to allow for such changes to land.
PR Close#42760
Skydoc is no longer used as `@angular/bazel` is no longer a
public API. The Sass rules were only used in a single place
in the repo where Sass is not really needed and has just been
added by accident most likely. We want to remove the Sass dependency
in preparation for Rules NodeJS v4.x where the Sass rules currently
still use an older version of `@bazel/worker` that is incompatible.
PR Close#42760
Rollup just prints a warning if an import cannot be resolved and ends up
being treated as an external dependency. This in combination with the
`silent = True` attribute for `rollup_bundle` means that bundles might
end up being extremely small without people noticing that it misses
actual imports.
To improve this situation, the warning is replaced by an error if
an import cannot be resolved.
This unveiles an issue with the `ng_rollup_bundle` macro from
dev-infra where imports in View Engine were not resolved but ended
up being treated as external. This did not prevent benchmarks using
this macro from working because the ConcatJS devserver had builtin
resolution for workspace manifest paths. Though given the new check
for no unresolved imports, this will now cause errors within Rollup, and
we need to fix the resolution. We can fix the issue by temporarily
enabling workspace linking. This does not have any performance
downsides.
To enable workspace linking (which we might need more often in the
future given the linker taking over patched module resolution), we
had to rename the `angular` dependency to a more specific one so
that the Angular linker could link into `node_modules/angular`.
PR Close#42760
When another navigation is triggered during an in-process navigation and
the `canceledNavigationResolution` is `'computed'`, we should not
attempt to restore the browser history using `history.go`. Doing that
would trigger a third navigation through the router which would conflict
with the new navigation that we were trying to process. Instead, we
treat this as a redirect and skip the history restoration attempt. This
acts similarly to returning `UrlTree` from a guard.
Fixes issue described in https://github.com/angular/angular/pull/38884#issuecomment-863767152
PR Close#42751
Previously, the ServiceWorker assumed that a client found in
`clientVersionMap` would exist (i.e. it could be retrieved via
`clients.get()`). However, if a browser tab had been closed, the
corresponding client (while present in `clientVersionMap`, which is only
updated on ServiceWorker initialization) would not be retrievable via
`clients.get()`.
This commit fixes it by checking whether the client exists before trying
to notify it about an unrecoverable state.
PR Close#42736
Previously, we used custom typings for the ServiceWorker environment.
This was necessary back when the ServiceWorker package was introduced,
since there were no official typings.
Since there are now official typings for Web Workers (including
ServiceWorkers) offered by TypeScript as [lib.webworker.d.ts][1], this
commit gets rid of our custom typings in favor of using the official
ones.
[1]: https://github.com/microsoft/TypeScript/blob/v4.3.4/lib/lib.webworker.d.ts
PR Close#42736
This commit better aligns the mock `ServiceWorkerGlobalScope`
implementation used in ServiceWorker tests (and the associated typings)
with the actual implementation (and the official TypeScript typings).
This allows verifying the ServiceWorker behavior in a slightly more
realistic environment.
This is in preparation of switching from our custom typings to the
official TypeScript typings (`lib.webworker.d.ts`).
PR Close#42736
This commit better aligns the mock client implementations used in
ServiceWorker tests (and the associated typings) with the actual
implementations (and the official TypeScript typings). This allows
verifying the ServiceWorker behavior in a slightly more realistic
environment.
This is in preparation of switching from our custom typings to the
official TypeScript typings (`lib.webworker.d.ts`).
PR Close#42736
In the ServiceWorker tests, we use mock implementations of the various
client APIs that the ServiceWorker interacts with. Previously, these
mock implementations were defined in the `testing/scope.ts` file. This
added several extra classes to a file that already contains a few,
making it harder to maintain.
Therefore, this commit moves these mock client classes to a separate
`testing/clients.ts` file.
PR Close#42736
This commit better aligns the mock event implementations used in
ServiceWorker tests (and the associated typings) with the actual
implementations (and the official TypeScript typings). This allows
verifying the ServiceWorker behavior in a slightly more realistic
environment.
This is in preparation of switching from our custom typings to the
official TypeScript typings (`lib.webworker.d.ts`).
PR Close#42736
In the ServiceWorker tests, we use mock implementations of the various
events emitted during the ServiceWorker lifecycle. Previously, these
mock implementations were defined in the `testing/scope.ts` file. This
added several extra classes to a file that already contains a few,
making it harder to maintain.
Therefore, this commit moves these mock event classes to a separate
`testing/events.ts` file.
PR Close#42736
This commit makes the `SwTestHarness.envIsSupported()` static method a
standalone function. This function is used to determine whether the
current environment provides the necessary APIs to run the SW tests and
is independent of `SwTestHarness`, so is no need for it to be a static
method of `SwTestHarness`.
This is in preparation of switching from our custom typings to the
official TypeScript typings (`lib.webworker.d.ts`).
PR Close#42736
This commit removes the duplicate `Context` interface and uses the
`ExtendableEvent` interface instead.
This is in preparation of switching from our custom typings to the
official TypeScript typings (`lib.webworker.d.ts`).
PR Close#42736
The ServiceWorker needs to keep track of some metadata for unhashed
asset resources to know if/when they might need to be revalidated. This
applies to resources that do not exist on the filesystem at build-time
(and thus cannot be hashed), such as fonts or images loaded from
external sources. For hashed resources, this metadata is irrelevant,
because the hash is enough to verify that the content hasn't changed and
no revalidation is necessary.
Previously, the ServiceWorker would store such metadata for hashed
resources as well, even though it would never be used (thus taking up
space unnecessarily).
This commit fixes it by not storing metadata for hashed resources, i.e.
those that are included in an asset-group's `hashes` array.
PR Close#42606
Source files that contain directives or components that need an inline
type constructor or inline template type-check block would always be
considered as affected in incremental rebuilds. The inline operations
cause the source file to be updated in the TypeScript program that is
created for template type-checking, which becomes the reuse program
in a subsequent incremental rebuild.
In an incremental rebuild, the source files from the new user program
are compared to those from the reuse program. The updated source files
are not the same as the original source file from the user program, so
the incremental engine would mark the file which needed inline
operations as affected. This prevents incremental reuse for these files,
causing sub-optimal rebuild performance.
This commit attaches the original source file for source files that have
been updated with inline operations, such that the incremental engine
is able to compare source files using the original source file.
Fixes#42543
PR Close#42759
DTS bundling, will cause originally namespaced imports become namespace declarations within the same file. Example:
Before bundling
```ts
import * as i1 from './router';
export declare class RouterModule {
constructor(guard: any, router: Router);
static ɵmod: i0.ɵɵNgModuleDeclaration<RouterModule, [typeof i1.RouterOutlet...]>;
}
```
After bundling
```
declare namespace i1 {
export {
RouterOutletContract,
RouterOutlet
}
}
export declare class RouterModule {
constructor(guard: any, router: Router);
static ɵmod: i0.ɵɵNgModuleDeclaration<RouterModule, [typeof i1.RouterOutlet...]>;
}
```
And therefore this commit adds support for reflecting types that are defined in such namespace declarations.
Closes#42064
PR Close#42728
Updates the api-extractor dependencies of the repository, and within
the `@angular/bazel` package so that TypeScript 4.3 is supported when
a flattened typings file is generated. Without this update, the api
extractor could fail if a referenced tsconfig use a TS 4.3-only option such as
`noImplicitOverride`.
Note: This could also be considered a `feat:` for `@angular/bazel`,
but this package is not part of the public API anyway and we'd want
that change to land in the patch branches too (to keep the goldens
in sync between release branches as much as possible)
PR Close#42737
Historically, our Language Service was built with the potential to be a
drop-in replacement for the TypeScript Language Service with the added
benefit of being able to provide Angular-specific information as well.
While our VSCode extension does not use the Language Service in this
way, it appears that other community-contributed plugins do. We don't
really officially support this use-case but there's not real reason for
us to override the TypeScript Language Service's
implementation in the VE Angular Language Service so that it returns
`undefined`. As with other non-implemented methods, we can just allow
this to be deferred to TSLS.
fixes#42715
PR Close#42727
When the template type checker try to get a symbol of a template node, it will
not return the directives intended for an element on a microsyntax template,
for example, `<div *ngFor="let user of users;" dir>`, the `dir` will be skipped,
but it's needed in language service.
Fixes https://github.com/angular/vscode-ng-language-service/issues/1420
PR Close#42640
When `TestBed.compileComponents` is called under ViewEngine, we kick off a compilation and return a promise that resolves once the compilation is done. In most cases the consumer doesn't _have_ to await the returned promise, unless their components have external resources.
The problem is that the test could be over by the time the promise has resolved, in which case we still cache the factory of the test module. This becomes a problem if another compilation is triggered right afterwards, because it'll see that we still have a `_moduleFactory` and it won't recreate the factory.
These changes resolve the issue by saving a reference to the module type that is being compiled and checking against it when the promise resolves.
Note that while this problem was discovered while trying to roll out the new test module teardown behavior in the Components repo (https://github.com/angular/components/pull/23070), it has been there for a long time. The new test behavior made it more apparent.
PR Close#42669
Paul Gschwendtner
Arthur Ming
Kristiyan Kostadinov
JoostK
behrooz bozorg chami
Alan Agius
Andrew Scott
Renovate Bot
Gabriele Franchitto
Borislav Ivanov
George Kalpakas
David Gilson
ivanwonder