The way that `UpgradeAdapter` needs to be setup, you often find that
you must pass a `forwardRef` for an `NgModule.import`. Pre-ivy, this
gets resolved at runtime, but until this is implemented in ivy, we can
workaround it by resolving it in the `UpgradeAdapter` upfront.
This should be backward-compatible since by the time we actually
create the dynamic `NgModule` that has the import, the imported
class should be defined.
PR Close#27132
When ngtsc compiles @angular/core, it rewrites core imports to the
r3_symbols.ts file that exposes all internal symbols under their
external name. When creating the FESM bundle, the r3_symbols.ts file
causes the external symbol names to be rewritten to their internal name.
Under ngcc compilations of FESM bundles, the indirection of
r3_symbols.ts is no longer in place such that the external names are
retained in the bundle. Previously, the external name `ɵdefineNgModule`
was explicitly declared internally to resolve this issue, but the
recently added `setClassMetadata` was not declared as such, causing
runtime errors.
Instead of relying on the r3_symbols.ts file to perform the rewrite of
the external modules to their internal variants, the translation is
moved into the `ImportManager` during the compilation itself. This
avoids the need for providing the external name manually.
PR Close#27055
Some engineers were already on Yarn 0.10.x which was permitted by the range in our package.json#engines
However this introduced 'integrity sha512' lines into the yarn.lock files.
Then when engineers use yarn 0.9 (in particular, Bazel did this) then the lock files get tons of meaningless edits.
We could force everyone back to yarn 0.9 but this commit chooses to instead advance everyone past 0.10
PR Close#27193
Now that the Ivy switch transform uses ts.getMutableClone() to copy
statements, there's no need to set .parent pointers on the resulting
updated nodes. Doing this was causing assertion failures deep in
TypeScript in some cases.
PR Close#27170
Currently the `useJit` option from `TestBed.configureCompiler` isn't supported. These changes rework the existing test suites not to pass in `useJit` when running with Ivy.
PR Close#27067
This option means guards and resolvers will ignore changes to optional
parameters such as query and matrix params. When the path or any path
params change, guards and resolvers will be run
Related to discussion in #18253
FW-560 #resolve
PR Close#26861
Make a copy of the ts.SourceFile before modifying it in the ivy_switch
transform. It's suspected that the Bazel tsc_wrapped host's SourceFile
cache has issues when the ts.SourceFiles are mutated.
PR Close#27032
In a more specific scenario: Considering people use a custom TypeScript compiler host with `NGC`, they _could_ expect only posix paths in methods like `writeFile`. This at first glance sounds like a trivial issue that should be just fixed by the actual compiler host, but usually TypeScript internal API's just pass around posix normalized paths, and therefore it would be good to follow the same standards when passing JSON genfiles to the `CompilerHost`.
For normal TypeScript files (and TS genfiles), this is already consistent because those will be handled by the actual TypeScript `Program` (see `emitCallback`).
PR Close#27062
Adds support for the `providers` that are passed in through `TestBed.configureCompiler` and scopes the error only if the consumer has passed in `useJit`.
PR Close#27066
This fixes an issue where packages would be skipped if they contained
e.g. RxJS 5 style imports such as
```
import { observeOn } from 'rxjs/operators/observeOn';
```
Given that no package.json file can be found at the imported path, the
dependency would be reported missing, causing the package to be skipped.
PR Close#27031
This API is part of our public api surface and needs to be monitored by the public_api_guard.
I also had to go back and mark all of the exported functions with @publicApi jsdoc tag.
PR Close#27008
Make the error messages thrown when instantiating downgraded components,
injectables and modules more descriptive and actionable, also taking
into account incorrect use of the `downgradedModule` field.
PR Close#26217
Currently, calling `downgradeModule()` more than once is not supported.
If one wants to downgrade multiple Angular modules, they can create a
"super-module" that imports all the rest and downgrade that.
This commit adds support for downgrading multiple Angular modules. If
multiple modules are downgraded, then one must explicitly specify the
downgraded module that each downgraded component or injectable belongs
to, when calling `downgradeComponent()` and `downgradeInjectable()`
respectively.
No modification is needed (i.e. there is no need to specify a module for
downgraded components and injectables), if an app is not using
`downgradeModule()` or if there is only one downgraded Angular module.
Fixes#26062
PR Close#26217
Previously the ivy definition calls we going directly after the
class constructor function But this meant that the lifecycle
hooks attached to the prototype were ignored by the ngtsc
compiler.
Now the definitions are written to the end of the IIFE block,
just before the return statement.
Closes#26849
PR Close#26856
- Format JSDoc for notificationClicks
- Add comment on why handleClick does not use hasOwnProperty
- Add additional test that uses handleClick without action
PR Close#25860