With this change we change ownership of `goldens/public-api/manage.js` from `public-api` to `dev-infra`. This file is a script to manage public-api golden files and therefore it should fall under the dev-infra umbrella.
PR Close#43664
Previously, all asset-groups from `ngsw-config.json` were processed in
parallel. For each asset-group, we retrieved all files for the current
build, filtered out files that were already matched by other
asset-groups, determined which of the remaining files belonged to the
current asset-group and generated entries for the `ngsw.json` manifest.
This process was susceptible to race conditions when there were files
that would be matched by multiple asset-groups. This made the generation
of the `ngsw.json` manifest non-deterministic and violated the rule that
each file would belong to the first asset-group that matched it (based
on the asset-groups' order of appearance in `ngsw-config.json`), thus
leading to broken ServiceWorker behavior.
This commit fixes it by ensuring that the generation process is
deterministic and that asset-groups are processed in the proper order.
NOTE 1:
The generation process has been broken since the beginning, but we have
only noticed this recently. This is possibly related to the CLI's
switching from a virtual file system host (which has more consistent
timing characteristics) to the Node.js built-in `fs.promises` in
angular/angular-cli@d3bc530c10.
NOTE 2:
This commit also ensures that files in the `ngsw.json` hash-table are in
alphabetic order. Previously, the files were added to the hash-table in
blocks corresponding to each asset-group.
This change is not necessary (i.e. the order of keys in the hash-table
makes no difference in behavior), but it makes it easier to scan for a
file (for example, for debugging purposes).
PR Close#43679
This commit introduces a new `SwUpdate#versionUpdates` observalbe, which provides more granular
information about Service Worker version updates than the already existing `SwUpdate#available`
observable.
The new events emitted by `SwUpdate#versionUpdates` basically add the possibility for application to
get notified if a new version is available on the server (not yet downloaded) and if an installation
of a new version failed.
Closes#39840
DEPRECATED: The `SwUpdate#availalbe` observable is deprecated.
The new `SwUpdate#versionUpdates` observable provides the same information and more. Therefore, it
is possible to rebuild the same behavior as `SwUpdate#availalbe` using the events emitted by
`SwUpdate#versionUpdates` and filtering for `VersionReadyEvent` events.
As a result, the `SwUpdate#availalbe` observable is now redundant.
PR Close#43668
Previously `activateUpdate` and `checkForUpdate` returned `Promise<void>`, which did not provide any
information of the actual outcome of the operation. Developers needed to subscribe to a
corresponding observable to obtain the outcome.
With this commit `SwUpdate#activateUpdate` will return `Promise<boolean>` which resolves to `true` if
an update was activated, to `false` if no new version is available and rejects in case of any error.
`SwUpdate#checkForUpdate` also returns a `Promise<boolean>` which resolves to `true` if an update is available, to `false` if no update was found and rejects in case of any error.
Closes#39840
BREAKING CHANGE: The return type of `SwUpdate#activateUpdate` and `SwUpdate#checkForUpdate` changed to `Promise<boolean>`.
Although unlikely, it is possible that this change will cause TypeScript type-checking to fail in
some cases. If necessary, update your types to account for the new
return type.
DEPRECATED: The `SwUpdate#activated` observable is deprecated.
The `SwUpdate#activated` observable only emits values as a direct response to calling
`SwUpdate#activateUpdate()` and was only useful for determining whether the call resulted in an
update or not. Now, the return value of `SwUpdate#activateUpdate()` can be used to determine the
outcome of the operation and therefore using `SwUpdate#activated` does not offer any benefit.
PR Close#43668
Previously, when a router-outlet is conditionally shown with an ngIf, and a sub-route was re-attached
via a custom RouteReuseStrategy, router-outlet would try to mount a destroyed component into the view
if the router-outlet is destroyed and re-initialized.
This commit fixes it by unsetting context.attachRef when router-outlet is destroyed, so when the
router-outlet is being initialized again, it no longer sees an attachRef that it needs to mount to the
view.
Fixes#43696
PR Close#43697
Fixes a unit test that now fails, because rethrowing errors is enabled by default. The problem is that we're checking the behavior of a component that throws during `ngOnDestroy`, but since the `resetTestingModule` call itself throws, the test is considered as failing.
PR Close#43714
Refs #42966.
Previously, checking a template with the syntax:
```html
<div>{{ foo() ?? 'test' }}</div>
```
Where `foo()` returns a nullable value:
```typescript
@Component(/* ... */)
class TestCmp {
foo: (): string | null => null;
}
```
Would always log a nullish coalescing not nullable warning. This is because [`getSymbolOfNode(node.left)`](https://github.com/angular/angular/blob/fe691935091aaf7090864c8111a15f7cc7e53b6c/packages/compiler-cli/src/ngtsc/typecheck/extended/checks/nullish_coalescing_not_nullable/index.ts#L30) would return the [symbol of the function (`foo`)](https://github.com/angular/angular/blob/fe691935091aaf7090864c8111a15f7cc7e53b6c/packages/compiler-cli/src/ngtsc/typecheck/src/template_symbol_builder.ts#L536-L538) rather than the symbol of its returned value (`foo()`). Fixed this by getting the symbol for the whole expression's span, rather than just the function receiver.
Also made some minor refactorings to `template_symbol_builder` to make a similar change to safe method calls. This behavior was originally for the language service in order to handle quick info, as the user highlighting a function name would actually apply to the entire expression. This is no longer true as the language service will correctly request the type from the function rather than the `Call` expression, so these hacks are not necessary anymore. This broke two existing test cases of exactly this behavior which were easily updated. Also added a test to the language service to confirm that it is not broken by this change.
PR Close#43572
`source-map` is only used during testing and therefore there is no need to list it as a dependency.
(cherry picked from commit ae7dc75bdce713acaa1658734791317a274982da)
PR Close#43644
Since the `destroyAfterEach` teardown behavior is enabled by default now, existing tests that depended on the old behavior can start to fail. These changes add an automated migration that explicitly adds `destroyAfterEach: false` to existing tests.
The migration works by looking for `initTestEnvironment` calls across the entire app and adding the flag to them. If no calls were found, the migration will add the flag to all `configureTestingModule` and `withModule` calls instead.
PR Close#43353
NgModule factories are obsolete with Ivy and most of the operations can already be performed with NgModule classes without retreieving corresponding factories. NgModule factories were useful to generate an `NgModuleRef` (via `NgModuleFactory.create` method). This commit adds a new function to create an instance of the `NgModuleRef` class without having the need to create a factory first.
PR Close#43580
This commit adds a new function called `getNgModuleById` to the public API surface of the framework. The `getNgModuleById` function allows to retrieve loaded NgModule class by id (specified via `@NgModule.id`). The function is a replacement for the `getModuleFactory` function.
DEPRECATION:
The `getModuleFactory` function is deprecated in favor of the `getNgModuleById` one. With Ivy it's possible to work with NgModule classes directly, without retrieving corresponding factories, so the `getNgModuleById` should be used instead.
PR Close#43580
When compiling your application using the AOT compiler, your templates
are type-checked according to a certain strictness level. Before Angular 9
there existed only two strictness levels of template type checking as
determined by [the `fullTemplateTypeCheck` compiler option](guide/angular-compiler-options).
In version 9 the `strictTemplates` family of compiler options has been
introduced as a more fine-grained approach to configuring how strict your
templates are being type-checked.
The `fullTemplateTypeCheck` flag is being deprecated in favor of the new
`strictTemplates` option and its related compiler options. Projects that
currently have `fullTemplateTypeCheck: true` configured can migrate to
the following set of compiler options to achieve the same level of
type-checking.
```json
{
"angularCompilerOptions": {
"strictTemplates": true,
"strictInputTypes": false,
"strictNullInputTypes": false,
"strictAttributeTypes": false,
"strictOutputEventTypes": false,
"strictDomEventTypes": false,
"strictDomLocalRefTypes": false,
"strictSafeNavigationTypes": false,
"strictContextGenerics": false,
}
}
```
PR Close#43224
The `skipTemplateCodegen`, `strictMetadataEmit` and
`enableResourceInlining` options are specific to ViewEngine and have no
effect when using the Ivy compiler. Since libraries can no longer be
compiled using ViewEngine from Angular 13, this commit removes these
options entirely.
The `annotateForClosureCompiler` is also no longer recommended to use,
as Closure Compiler is not supported outside of Bazel.
Finally, the `fullTemplateTypeCheck` flag is changed into
`strictTemplates` as the former flag is being deprecated. Enabling
`strictTemplates` does result in more strict type-checking than with
only `fullTemplateTypeCheck` enabled, but simply removing
`fullTemplateTypeCheck` right away would result in less strict
type-checking which is not desired.
PR Close#43224
when some auto code links fail to happen they can be added manually
with the md ``[`code text`](link)``, these generate anchor elements which
contain a code element, such code element does not get the correct text
color, this commit fixes such issue
PR Close#43586
remove the deprecated tslint from the examples of type cli
note: eslint hasn't be applied and linting has been removed entirely
to follow angular's unopinionated view on linting
PR Close#43592
Update the AIO scripts that use Lighthouse (i.e. `audit-web-app.js` and
`test-aio-a11y.js`) to ES modules. This allows consuming
`lighthouse/lighthouse-cli` [v8.5.0+][1], which also switched to ES
modules.
NOTE:
Switching the `test-aio-a11y.js` script to ES modules is not strictly
necessary, since it invokes `audit-web-app.mjs` via a shell command, but
it was done for consistency.
[1]: https://github.com/GoogleChrome/lighthouse/releases/tag/v8.5.0
PR Close#43607
The `@angular/core` migrations are currently published as CommonJS and also not bundled. Schematics, of which migrations are a type, are currently required to be CommonJS modules due to the Schematics Runtime not yet supporting ESM-based schematics. To ensure that the migration files are loaded as CommonJS modules, a nested `package.json` file has been introduced within the `schematics` directory of the package to set the `type` field for all containing JavaScript files as CommonJS. Since the migrations are also not currently bundled and the `devmode` output used to build the migrations will replace all relative imports with fully-qualified module specifiers, an additional `exports` entry must be added to allow the fully-qualified module specifiers to correctly resolve. If `devmode` did not change the relative imports the additional entry would not be needed. Bundling would also remedy the situation and is the long-term path, especially once the migrations are converted to ESM. Additional followup changes should investigate bundling each migration. The additional `exports` entry should be removed if either `devmode` behavior is changed or the migrations are bundled.
PR Close#43657
Currently, migrations and schematics must be in CommonJS format. However, framework packages will only be ESM from v13 and onward. To support this configuration, dynamic import expressions are now used to load `@angular/compiler-cli` and its new secondary entry point `@angular/compiler-cli/private/migrations`. Dynamic imports within Node.js allow the `@angular/core` migrations’ CommonJS code to load ESM code. Unfortunately, TypeScript will currently, unconditionally down-level dynamic import into a require call. `require` calls cannot load ESM code and will result in a runtime error. To workaround this, a Function constructor is used to prevent TypeScript from changing the dynamic import. Once TypeScript provides support for keeping the dynamic import this workaround can be dropped and replaced with a standard dynamic import. Due to the use of the dynamic import, a reference to the dynamically loaded modules must now be passed to all locations that use values from the modules.
PR Close#43657
The Router code currently has special-case handling around when and how
the internal state is reset. Specifically, it only resets the internal
tracking of the state when an error is thrown, which does not happen
when guards reject or resolvers return `EMPTY`. Other than the
navigation URL not matching a config, guards rejecting would be the main
cause of a navigation being turned down.
This change updates the router code to always reset the internal state
in the same way, regardless of the reason for navigation cancellation.
In the end, this will only affect _very_ specific use-cases with
`UrlHandlingStrategy`. Because the internal state is not updated until
the end of the transition pipe, the state reset generally doesn't do
anything at all. However, because the `rawUrlTree` is reset by calling
`urlHandlingStrategy.merge` with the _attempted_ `rawUrl` that failed,
the resulting browser URL reset could be different than before (but will
now be consistent with how the URL is reset in other scenarios, like a
URL not matching a `Route` config).
PR Close#43651
Internally, g3 code still uses the `loadChildren: string` syntax. We
need to continue to provide this functionality with an internal patch.
This change makes that patch easier by only touching stub files that
support the `loadChildren: string` (other than `router_config_loader`).
PR Close#43660
DEPRECATION:
The template prefixes `bind-`, `on-`, `bindon-`, and `ref-` have been deprecated
in v13. Templates should use the more widely documented syntaxes for binding and references:
* `[input]="value"` instead of `bind-input="value"`
* `[@trigger]="value"` instead of `bind-animate-trigger="value"`
* `(click)="onClick()"` instead of `on-click="onClick()"`
* `[(ngModel)]="value"` instead of `bindon-ngModel="value"`
* `#templateRef` instead of `ref-templateRef`
PR Close#43671
Updates the size goldens for the integration CLI tests to
reflect the new payload with APF v13 and the CLI v13-next.7
Overall, there seems to be some increase in the polyfills
and a ~400b increase for the `main` bundles. This seems to
because with APF v13, the core package no longer uses the
downleveled `Object.assign`, but the spread operator directly.
ESbuild will then downlevel the spread to `__spreadProps` which
seems to come with more transitively-required helpers that
end up contributing to the ~400b increase. The spread is downleveled
even for the modern browsers this integration test targets, because
it is a trick to wrokaround a performance bug in V8. So the size
increase is reasonable given the runtime improvement. More details
here:
https://github.com/evanw/esbuild/issues/951#issuecomment-796972298.
PR Close#43431
Updates the size goldens for the two AIO production build jobs.
Due to the removal of differential loading, the bundle names no
longer include the ES version being used, so we remove that suffix.
The styles overall decreased. Additionally, the main bundle became
noticable smaller, with a little increase in the polyfills. The AIO
job not using APF v13 seems larger but this is likely due to the current
Angular v13 packages (in the `test_aio`) job still using View Engine
APF v12 with the CLI v13 (where some optimizations might not match up anymore).
PR Close#43431
This commits sets the JS target for all command line tools to
NodeJS v12. ESbuild will automatically downlevel the ES2020 features
we currently use to make them compatible with NodeJS v12 <-> ES2019.
ES2020 is the prodmode output, but we still support Node v12 so
there needs to be some downleveling for now.
Note: This is a separate commit because initially the target was
set to Node v14 to match up with the prodmode Bazel output.
PR Close#43431
Simplifies the `last_segment_name` computation in the integration
test Starlark macro we use. The last segment name could be computed
in a shorter way and this has come up while being at it (through review;
so this commit addresses that).
PR Close#43431
Similar to the other private entry-points we have added for localize,
bazel or the migrations, we should expose the tooling code through
a dedicated private export. This will make the compiler-cli exports
more consistent and it will become easier for the CLI to export
necessary code.
PR Close#43431
Currently, some tests in the `compiler-cli/integrationtest` package fail
on Windows because there are spec files which are not Bazel-generated.
When Bazel runs these tests on Windows, the spec file is resolved to
the actual source file (since there is no runfile symlinking/sandboxing).
This breaks the execution of the CJS spec file since it resides in th
`packages/compiler-cli` source folder which has a `package.json` set to
`type: module`.
We fix this by adding a `package.json` file for the integration test
folder and setting `module` to `commonjs`.
PR Close#43431
The package builder script should respect the `BAZEL` environment
variable for running Bazel. If not set, it can fallback to bazelisk
from the `node_modules`. Respecting this variable allows for users
with a global `bazel` binary. This is desirable in some situations,
like on Windows, where running Bazel inside of the Yarn environment
seems slower than running a global variant. This could appear like that
because projects might use different Bazel versions. In some cases,
developers would want to use a single (already-warmed-up) instance of
Bazel instead of launching different versions using bazelisk.
(e.g. when switching a lot between repos like COMP, FW or CLI..)
In any case, it doesn't hurt providing this flexibility for advanced
use-cases. It's low-effort to maintain and is respected in COMP as well.
PR Close#43431
Temporarily disables the Bazel integration test as it will not
work with the APF v13 output which is strict ESM. We need to
land some logic in `rules_nodejs` first that would allow an
ESM variant of `@angular/compiler-cli` to work.
Once this happened and there is a new release, we can re-enable
the test and make adjustments for v13 APF (i.e. running the linker
plugin when creating the rollup bundles).
PR Close#43431
This commit temporarily disables the SystemJS upgrade e2e tests. All of
the upgrade e2e tests (except for `phonecat-1-typescript`) rely on UMD
bundles. These are no longer available for the v13 Angular package
output, so we disable the tests for now.
These e2e tests can be re-enabled once we migrated the exampels from
UMD bundles to e.g. the CLI, or some custom rollup build. Alternatively
it might be even possible to use FESM bundles directly (depending on
browser support for the AIO examples; this is something the docs-infra
team will have to determine though).
PR Close#43431
With the APF v13 package output, deep files can no longer be imported.
Since we do not intend to bundle the compiler into the compiler-cli, we
need to switch all deep imports to the primary entry-point.
PR Close#43431
We updated the dev-infra version as part of the v13 package format
in order to be able to use the latest `rollup` version (and its
plugins). The update of the shared dev-infra package resulted in an
update of Chromium to a more recent version. This version of Chromium
seems to normalize the `content-type` header differently, so that the
AIO `http` example test assertion needs to be updated to work with the
new version of chromium. This commits updates the test.
PR Close#43431
Adding suites to the `IGNORED_EXAMPLES` array currently results
in an runtime exception because later when ignored examples are
printed to stdout, a non-existent variable is referenced back
from when there were examples disabled due to the Ivy migration.
This commit fixes the logic.
PR Close#43431
Updates the `hello_world_closure` integration test to use APF v13
in combination with the linker plugin which is needed as running
the `ngc` command standalone does not modify the `node_modules`
and the FW packages remain partially compiled. A step in between
using rollup can create a linker-processed bundle of all FW
packages.
PR Close#43431
Alan Agius