Currently internally Angular has some customized tsconfig files, because we don't align with the tsconfig of the rest of g3. These changes enable `noImplicitReturns` and `noPropertyAccessFromIndexSignature` to align better with the internal config.
PR Close#51728
Previously, [UpgradeModule#bootstrap()][1], while being a replacement
for and accepting the same arguments as [angular.bootstrap()][2], did
not return the same value as `angular.bootstrap()` (i.e. the AngularJS
injector in most cases). This made it less straight forward to migrate
some usecases that relied on the return value of `.bootstrap()`. The
work-around was to access the injector via [UpgradeModule#$injector][3]
(after the app had been bootstrapped with `UpgradeModule#bootstrap()`).
This commit addresses this by ensuring `UpgradeModule#bootstrap()`
returns the same value as `angular.bootstrap()`, making it easier to
replace the latter with the former.
[1]: https://angular.io/api/upgrade/static/UpgradeModule#bootstrap
[2]: https://docs.angularjs.org/api/ng/function/angular.bootstrap
[3]: https://angular.io/api/upgrade/static/UpgradeModule#%24injectorFixes#46211
PR Close#46214
Bundle spec files similar to how it is done within the Angular
Components repo. This should simplify the setup and also speed
up the Saucelab job as only a single spec bundle would need to be
downloaded, compared to having to load hundreds of files through the
Saucelabs tunnel.
Also makes a couple of tests more robust with the emulators/and accounts
for ES2015 test runner changes. The tests should be less reluctant to
such build process changes.
Note for reviewers: Some imports have been simplified here. This work
came from Joey's original WIP for this. It's unclear to me whether this
is still needed, but it sounded like this was necessary for the ESBuild
bundling to work. I have robusted the module resolution plugin though,
so I doubt it's still needed. At the same time though: Not worth
reverting/trying as these changes are nice to have anyway!
Co-Authored-By: Joey Perrott <josephperrott@gmail.com>
Co-Authored-By: Paul Gschwendtner <paulgschwendtner@gmail.com>
PR Close#44281
This commit removes special functions that were used to run tests in ViewEngine or Ivy only.
Since ViewEngine is deprecated and we no longer run ViewEngine tests on CI, we can cleanup
those special helpers and ViewEngine-only tests.
PR Close#44120
This commit extends the logic of the `downgradeModule` function to support NgModule class as an argument. This is needed to simplify the API surface to avoid the need to resolve NgModule factory before invoking the `downgradeModule` method.
PR Close#43973
Previously, due to the way the AngularJS and Angular clean-up processes
interfere with each other when removing an AngularJS element that
contains a downgraded Angular component, the data associated with the
host element of the downgraded component was not removed. This data was
kept in an internal AngularJS cache, which prevented the element and
component instance from being garbage-collected, leading to memory
leaks.
This commit fixes this by ensuring the element data is explicitly
removed when cleaning up a downgraded component.
NOTE:
This is essentially the equivalent of #26209 but for downgraded (instead
of upgraded) components.
Fixes#39911Closes#39921
PR Close#39965
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
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
