This commit improves the error thrown by the downgrade module with a more
descriptive message on why the downgrade is failing.
Closes#37579
PR Close#38671
1. update jasmine to 3.5
2. update @types/jasmine to 3.5
3. update @types/jasminewd2 to 2.0.8
Also fix several cases, the new jasmine 3 will help to create test cases correctly,
such as in the `jasmine 2.x` version, the following case will pass
```
expect(1 == 2);
```
But in jsamine 3, the case will need to be
```
expect(1 == 2).toBeTrue();
```
PR Close#34625
There were some extra examples for `downgradeComponent()` in the upgrade
guide. Added a link to the relevant section of the guide in the
`downgradeComponent()` docs.
Fixes#31584
PR Close#34406
This is a breaking change in nodejs rules 0.40.0 as part of the API review & cleanup for the 1.0 release. Their APIs are identical as ts_web_test was just karma_web_test without the config_file attribute.
PR Close#33802
Using `ParentInjectorPromise.all()` (which is a static method inherited
from `SyncPromise`) causes Closure Compiler (or some related tool) to
complain:
```
TypeError: ...$packages$upgrade$src$common$src$downgrade_component_ParentInjectorPromise.all is not a function
```
Switching to `SyncPromise.all()` (the static method on the parent class)
to avoid this error.
PR Close#31986
AngularJS compilation is a synchronous operation (unless having to fetch
a template, which is not supported for downgraded components).
Previously, ngUpgrade tried to retain the synchronous nature of the
compilation for downgraded components (when possible), by using a
synchronous thenable implementation (`ParentInjectorPromise`). This was
accidentally broken in #27217 by replacing a call to
`ParentInjectorPromise#then()` (which can be synchronous) with a call to
`Promise.all()` (which is asynchronous).
This commit fixes this by introducing a `SyncPromise.all()` static
method; similar to `Promise.all()` but retaining the synchronous
capabilities of `SyncPromise` (which `ParentInjectorPromise` inherits
from).
Fixes#30330
PR Close#31840
Fixes all TypeScript failures caused by enabling the `--strict`
flag for test source files. We also want to enable the strict
options for tests as the strictness enforcement improves the
overall codehealth, unveiled common issues and additionally it
allows us to enable `strict` in the `tsconfig.json` that is picked
up by IDE's.
PR Close#30993
Adds two new helper functions that can be used when unit testing Angular services
that depend upon upgraded AngularJS services, or vice versa.
The functions return a module (AngularJS or NgModule) that is configured to wire up
the Angular and AngularJS injectors without the need to actually bootstrap a full
hybrid application.
This makes it simpler and faster to unit test services.
PR Close#16848
With #30058, the ngUpgrade internal `angular.module()` method was
renamed to `angular.module_()` (to avoid a webpack bug).
Merging #29794 afterwards resulted in some broken tests, because it
still used the old `angular.module()` method name. (The PR had been
tested on CI against a revision that did not contain the rename.)
This commit fixes the broken tests by renaming the remaining occurrences
of `angular.module()`.
PR Close#30126
Previously, under certain circumstances, `NgZone#onMicrotaskEmpty` could
emit while a `$digest` was in progress, thus triggering another
`$digest`, which in turn would throw a `$digest already in progress`
error. Furthermore, throwing an error from inside the `onMicrotaskEmpty`
subscription would result in unsubscribing and stop triggering further
`$digest`s, when `onMicrotaskEmpty` emitted.
Usually, emitting while a `$digest` was already in progress was a result
of unintentionally running some part of AngularJS outside the Angular
zone, but there are valid (if rare) usecases where this can happen
(see #24680 for details).
This commit addresses the issue as follows:
- If a `$digest` is in progress when `onMicrotaskEmpty` emits, do not
trigger another `$digest` (to avoid the error). `$evalAsync()` is used
instead, to ensure that the bindings are evaluated at least once more.
- Since there is still a high probability that the situation is a result
of programming error (i.e. some AngularJS part running outside the
Angular Zone), a warning will be logged, but only if the app is in
[dev mode][1].
[1]: https://github.com/angular/angular/blob/78146c189/packages/core/src/util/ng_dev_mode.ts#L12Fixes#24680
PR Close#29794
When targeting ES2015 (as is the default in cli@8), `const` is not
downleveled to `var` and thus declaring `const module` throws an error
due to webpack wrapping the code in a function call with a `module`
argument (even when compiling for the `web` environment).
Related: webpack/webpack#7369
Fixes#30050
PR Close#30058
Previously we had to share code between upgrade/dynamic and upgrade/static
by symlinking the `src` folder, which allowed both packages to access
the upgrade/common files.
These symlinks are always problematic on Windows, where we had to run
a script to re-link them, and restore them.
This change uses Bazel packages to share the `upgrade/common` code,
which avoids the need for symlinking the `src` folder.
Also, the Windows specific scripts that fixup the symlinks have also
been removed as there is no more need for them.
PR Close#29466
At the moment, the API extractor doesn't support local namespaced imports, this will break the generation of flat dts files. When we turn on dts bundling for this package it will break. Hence this is the ground work needed for making this package compatable with the API extractor.
See: https://github.com/Microsoft/web-build-tools/issues/1029
Relates to #28588
PR Close#28642
Destroys the module's injector when an `NgModule` is destroyed which in turn calls the `ngOnDestroy` methods on the instantiated providers.
This PR resolves FW-739.
PR Close#27793
Previously, nested downgraded components would not be created/destroyed
inside the Angular zone (as they should) and they would not be wired up
correctly for change detection.
This commit ensures that ngUpgrade correctly detects whether this is an
ngUpgradeLite app (i.e. one using `downgradeModule()` instead of
`UpgradeModule`) and appropriately handles components, even if they are
nested inside other downgraded components.
Fixes#22581Closes#22869Closes#27083
PR Close#27217
In ngUpgrade (dynamic) we create a dynamic Angular `Directive` that wraps AngularJS components
that are being upgraded. The constructor of this `Directive` class returns a different instance
than `this`. It is this instance that actually contains the life-cycle hook handlers.
This would break in ivy, since the methods on the prototype of the original class are wired up,
rather than the instance methods. This results in hooks like `ngOnInit` not being called.
This commit refactors the code to extend the inner class that was being returned so that the
prototype chain is correct for both ViewEngine and ivy.
This change resolves a number of failing ivy tests, but also exposes other failures that were
masked by this issue. The tests have been updated accordingly.
(FW-812)
PR Close#27660
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
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
Sonu Kapoor
JiaLiPassion
Joey Perrott
Paul Gschwendtner
ajitsinghkaler
Greg Magolan
NothingEverHappens
Evan Martin
Danny Skoog
Carlos Ortiz García
George Kalpakas
Ben Black
Pete Bacon Darwin
Sam Julien
Alan
Kristiyan Kostadinov
Andy Blatecky
Jason Bedard
Jason Aden