This commit updates the `node` engines range for all Angular
framework packages to:
* No longer support NodeJS v12 `< 12.20`. This is done because APF v13
uses package export patterns which are only supported as of v12.20.
https://nodejs.org/api/packages.html#packages_subpath_patterns.
* Allows for the latest v16 NodeJS versions. This matches with the CLI
which added NodeJS v16 support with https://github.com/angular/angular-cli/pull/21854.
We already limit this to `>= v16.10.0` in preparation to only
supporting the LTS minors of Node v16.
BREAKING CHANGE: NodeJS versions older than `v12.20.0` are no longer
supported due to the Angular packages using the NodeJS package exports
feature with subpath patterns.
PR Close#43740
DEPRECATION:
In ViewEngine, [JIT compilation](https://angular.io/guide/glossary#jit) required special providers (like `Compiler`, `CompilerFactory`, etc) to be injected in the app and corresponding methods to be invoked. With Ivy, JIT compilation takes place implicitly if the Component, NgModule, etc have not already been [AOT compiled](https://angular.io/guide/glossary#aot). Those special providers were made available in Ivy for backwards-compatibility with ViewEngine to make the transition to Ivy smoother. Since ViewEngine is deprecated and will soon be removed, those symbols are now deprecated as well:
- `ModuleWithComponentFactories`
- `Compiler`
- `CompilerFactory`
- `JitCompilerFactory`
- `NgModuleFactory`
Important note: this deprecation doesn't affect JIT mode in Ivy (JIT remains available with Ivy).
PR Close#43710
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
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
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
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
As outlined in the previous commit which enabled the `esModuleInterop`
TypeScript compiler option, we need to update all namespace imports
for `typescript` to default imports. This is needed to allow for
TypeScript to be imported at runtime from an ES module.
Similar changes are needed for modules like `semver` where the types incorrectly
suggest named exports that will not exist at runtime when imported from ESM.
This commit refactors all imports to match with the lint rule we have
configured in the previous commit. See the previous commit for more
details on why certain imports have been changed.
A special case are the imports to `@babel/core` and `@babel/types`. For
these a special interop is needed as both default imports, or named
imports break the other module format. e.g default imports would work
well for ESM, but it breaks for CJS. For CJS, the named imports would
only work, but in ESM, only the default export exist. We work around
this for now until the devmode is using ESM as well (which would be
consistent with prodmode and gives us more valuable test results). More
details on the interop can be found in the `babel_core.ts` files (two
interops are needed for both localize/or the compiler-cli).
PR Close#43431
Enables the `esModuleInterop` for all TypeScript compilations in the
project. This allows us to emit proper ESM-compatible code. e.g.
consider the following import:
```ts
import * as ts from 'typescript';
```
This import currently will break at runtime in NodeJS because the
`typescript` package is not shipping ESM. It's still a CommonJS module.
ES modules are able to import from `typescript` though, using an import
statement as above, but everything in `module.exports` is being exposed
as the `default` named export. TypeScript at runtime does not have any
other named exports, so for actual ESM compatibility, all of our imports
need to be switched to:
```
import ts from 'typescript';
```
The `esModuleInterop` option allows this to work even though the
`d.ts` file of TS currently suggests that there are _only_ named exports.
The TypeScript language service will now suggest the correct import form as
shown above. It doesn't enforce that unfortunately, but this commit also
adds a lint rule that enforces certain patterns so that we emit imports
that are compatible with both ESM and CJS output (CJS still needed here
since tests run with CJS devmode output still; this is a future project
to switch that over to ESM!)
PR Close#43431
In order to support ESM for the `platform-server` package, we need to
remove two usages of dynamic imports and replace them with their
corresponding/equivalent import statement. This will also allow ESBuild
to recognize this import. Note that we want to keep these imports external, so
we explicitly specify the `externals` option for the `ng_package` rule.
PR Close#43431
The Angular Core and localize package currently use deep imports for
code that is shipped. This is problematic as we want to ship the
compiler-cli as full-ESM. To achieve this we need to use a bundler and
this breaks deep imports.
We use a bundler for the compiler CLI because for full ESM
compatibility, we would need to explicitly add the `.js` extension
to all relative imports. This is very cumbersome and prone to mistakes
so to mitigate this problem in a safe way, we bundle the compiler-cli.
Note: Deep imports continue to exist for the language service as it
bundles the compiler-cli.
PR Close#43431
After updating to a more recent version of rollup, rollup started to
complain because the `inject` and `ɵɵinject` functions are being re-exported
twice in the `@angular/core` public API entry-point.
Rollup threw errors like:
```
[!] Error: “ɵɵinject” cannot be exported from node_modules/@angular/core/esm2015/src/di/injector_compatibility.js as it is a reexport that references itself.
```
A similar error is shown for `CodegenComponentFactoryResolver`.
It seems like Rollup ideally would not throw here, similar to TypeScript
which detects that these exports are the same and just dedupes them, but
it's low-effort fixing this for now.
PR Close#43431
For APF v13, terser has been updated to v5, and the prodmode output
has changed from ES2015 to ES2020. This results in some changes in
the symbol extractor test. Here are the two causes of changes:
* As said in the previous commit, Terser drops the initializer for
variables which are set to `undefined`. We have updated the symbol
extractor to always capture such declarations w/o initializer now.
This means that a couple of declarations that a couple of new
symbols are captured now. These previously didn't have an initializer
even without Terser, and just didn't show up before.
* Terser changed its inline mechanism for functions that recursively
call themselves. Such functions are no longer inlined and therefore
show up in goldens now.
PR Close#43431
With the changes to support APF v13 in the `ng_package` rule, we have
removed the ambiguous `entry_point` attribute. The attribute suggested
that it would be used for determining the primary entry-point input
file. This was not the case as the flat module output file is consulted
for bundling et at. The attribute has been renamed to match its
purposed (renamed to `primary_bundle_name`).
We no longer need to set that attribute because the primary bundle
name is (1) not of relevance for consumers and (2) the rule already
infers the bundle name properly from the Bazel package.
PR Close#43431
In 3.6.0 jasmine added a required `pp` parameter to the `jasmineToString()` function
signature. This commit updates our own use of this signature to ensure that compilation
succeeds with the latest jasmine typings.
PR Close#43411
This commit removes the `WrappedValue` public API from `@angular/core`
which was deprecated in Angular 10 without replacement.
BREAKING CHANGE:
The `WrappedValue` class can no longer be imported from `@angular/core`,
which may result in compile errors or failures at runtime if outdated
libraries are used that are still using `WrappedValue`. The usage of
`WrappedValue` should be removed as no replacement is available.
PR Close#43507
This commit fixes an oversight in the JIT compilation of partial factory
declarations, where the literal `'invalid'` was not accounted for
(unlike the AOT linker).
Fixes#43609
PR Close#43619
This reverts commit ab3de40ba3, which is
itself a revert of the original commit. Thus, this restores the changes
to schematics in support of ESM.
Now that g3 has a local modification for load_esm, we can restore this
functionality.
PR Close#43637
This commit removes the ability to configure lazy routes using a string
for `loadChildren`, together with the supporting classes to load an
`NgModuleFactory` at runtime.
BREAKING CHANGE:
It is no longer possible to use `Route.loadChildren` using a string
value. The following supporting classes were removed from
`@angular/core`:
- `NgModuleFactoryLoader`
- `SystemJsNgModuleFactoryLoader`
The `@angular/router` package no longer exports these symbols:
- `SpyNgModuleFactoryLoader`
- `DeprecatedLoadChildren`
The signature of the `setupTestingRouter` function from
`@angular/core/testing` has been changed to drop its `NgModuleFactoryLoader`
parameter, as an argument for that parameter can no longer be created.
PR Close#43591
With Ivy it's possible to create a `ComponentFactory` instance based on the generated Component def, thus the `ViewContainerRef.createComponent` can accept a Component instance and create a factory inside, rather than requiring additional complexity of creating a ComponentFactory outside (by invoking `ComponentFactoryResolver`).
This should simplify the API that is used for creating components dynamically.
DEPRECATION:
Angular no longer requires component factories to dynamically create components. The factory-based signature of the `ViewContainerRef.createComponent` function is deprecated in favor of a different signature that allows passing component classes instead.
PR Close#43022
DEPRECATION:
In Ivy, AOT summary files are unused. Passing AOT summary files in TestBed has no effect, so the `aotSummaries` usage in TestBed is deprecated and will be removed in a future version of Angular.
PR Close#43395
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`. 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 compiler module must now be passed to all locations that use values from the `@angular/compiler` package.
PR Close#43627
A base class that can be used to implement a Render3 Template AST visitor is now used throughout the `@angular/core` migrations. This class is used instead of the `NullVisitor` found within the `@angular/compiler` because the `NullVisitor` requires a deep import which is no longer supported with the ESM bundled packages as of v13. The `NullVisitor` is also fairly trivial in regards to its implementation and the new base class also provides additional helper methods for migration specific behavior. This removes all remaining deep imports of the `@angular/compiler` package from the `@angular/core` migrations while avoiding the need to modify the `@angular/compiler` package.
PR Close#43627
Most of the deep imports into the `@angular/compiler` package in the `@angular/core` migrations are for template AST types that are available as exports from the main entry point of the package (albeit under slightly different names). For the available main entry point exports, the deep imports have been transitioned to no longer use the deep import.
PR Close#43627
DEPRECATION:
Ivy made it possible to avoid the need to resolve Component and NgModule factories. Framework APIs allow to use Component and NgModule Types directly. As a result, the `PlatformRef.bootstrapModuleFactory` and a factory-based signature of the `ApplicationRef.bootstrap` method are now obsolete and are now deprecated.
The `PlatformRef.bootstrapModuleFactory` calls can be replaced with `PlatformRef.bootstrapModule` ones. The `ApplicationRef.bootstrap` method allows to provide Component Type, so this can be used a replacement for the factory-based calls.
PR Close#43560
Adds support for TypeScript 4.4. High-level overview of the changes made in this PR:
* Bumps the various packages to `typescript@4.4.2` and `tslib@2.3.0`.
* The `useUnknownInCatchVariables` compiler option has been disabled so that we don't have to cast error objects explicitly everywhere.
* TS now passes in a third argument to the `__spreadArray` call inside child class constructors. I had to update a couple of places in the runtime and ngcc to be able to pick up the calls correctly.
* TS now generates code like `(0, foo)(arg1, arg2)` for imported function calls. I had to update a few of our tests to account for it. See https://github.com/microsoft/TypeScript/pull/44624.
* Our `ngtsc` test setup calls the private `matchFiles` function from TS. I had to update our usage, because a new parameter was added.
* There was one place where we were setting the readonly `hasTrailingComma` property. I updated the usage to pass in the value when constructing the object instead.
* Some browser types were updated which meant that I had to resolve some trivial type errors.
* The downlevel decorators tranform was running into an issue where the Closure synthetic comments were being emitted twice. I've worked around it by recreating the class declaration node instead of cloning it.
PR Close#43281
Currently the compiler has three different classes to represent a "call to something":
1. `MethodCall` - `foo.bar()`
2. `SafeMethodCall` - `foo?.bar()`.
3. `FunctionCall` - Any calls that don't fit into the first two classes. E.g. `foo.bar()()`.
There are a few problems with this approach:
1. It is inconistent with the TypeScript AST which only has one node: `CallExpression`.
2. It means that we have to maintain more code, because the various parts of the compiler need to know about three node types.
3. It doesn't allow us to easily implement some new JS features like safe calls (e.g. `foo.bar?.())`).
These changes rework the compiler so that it produces only one node: `Call`. The new node behaves similarly to the TypeScript `CallExpression` whose `receiver` can be any expression.
There was a similar situation in the output AST where we had an `InvokeMethodExpression` and `InvokeFunctionExpression`. I've combined both of them into `InvokeFunctionExpression`.
PR Close#42882
The previous replacement logic would not account for the CRLF line
endings when applying replacements because it would replace the whole
template with `template.content.length` which would not account for
CRLF. This update applies individual expression edits at each location
in the template rather than attempting to replace the whole template
contents with a new string that contains the migrations.
fixes#43416
PR Close#43519
The migration was previously touching files that did not have any
expressions to migrate. This change ensures that the migration doesn't
commit any updates on files that do not need them.
This change, however, does not address the underlying issue with the
migration and CRLF (which is fixed in a follow-up change).
Related to #43416
PR Close#43519
Introduce two new bazel rules: tsec_test and tsec_config, for
describing the tsec checks and the tsconfig file needed for such
checks, respectively. Currently, tsec_test only checks the srcs
of a ts_library or ng_module. It does not check direct or transitive
dependencies. Also, tsconfig files need to be manually maintained
to make sure tsec can read all necessary input (including global
symbols).
PR Close#43108
tsec is a static analyzer that discovers Trusted Types violations.
Deploy tsec to make sure there will be no TT regression in several
critical packages, including core, platform-browser, platform-server
and their dependencies. Existing violations have been reviewed and
exempted in packages/tsec-exemption.json. Future changes to the
exemption list requires security review.
PR Close#43108
With this change we change the logic to locate the tsconfig files. The public API to locate, read and parse the workspace configuration should be use instead of the custom implemented logic.
The custom implemented logic depended on methods which have long been deprecated and are not removed in version 13 of the Angular CLI. This was not caught during development/UT because this repo is using outdated Angular Tooling packages.
This change also updates a number of spec files which previously creating an invalid Angular workspace configuration file.
Closes#43334
PR Close#43343
The current behavior of `routerLink` for `null` and `undefined` inputs is to treat
the input the same as `[]`. This creates several unresolvable issues with
correctly disabling the links because `commands = []` does _not_ behave the same
as disabling a link. Instead, it navigates to the current page, but will also
clear any fragment and/or query params.
The new behavior of the `routerLink` input will be to completely disable navigation
for `null` and `undefined` inputs. For HTML Anchor elements, this will also mean
removing the `href` attribute.
Fixes#21457Fixes#13980Fixes#31154
BREAKING CHANGE:
Previously `null` and `undefined` inputs for `routerLink` were
equaivalent to empty string and there was no way to disable the link's
navigation.
In addition, the `href` is changed from a property `HostBinding()` to an
attribute binding (`HostBinding('attr.href')`). The effect of this
change is that `DebugElement.properties['href']` will now return the
`href` value returned by the native element which will be the full URL
rather than the internal value of the `RouterLink` `href` property.
PR Close#43087
The previous behavior of `RouterLink` for `null` and `undefined` inputs was to treat
the input the same as `[]` or `''`. This creates several unresolvable issues with
correctly disabling the links because `commands = []` does not behave the same
as disabling a link. Instead, it navigates to the current page, but will also
clear any fragment and/or query params.
The new behavior of the `routerLink` input will be to completely disable navigation
for `null` and `undefined` inputs. For HTML Anchor elements, this will also mean
removing the `href` attribute.
Migration for change in #43087
PR Close#43176
Class static properties with initializers that cause code execution (for example, call expressions or new expressions) have the potential to cause side effects at module evaluation. This is similar in effect to module level code. As a result, optimizers can not safely remove a class with such a static property as the potential side effects may have meaningful effects on the state of the application execution. To allow classes with these type of static properties to be optimized and removed if unused, the initializer expressions for the static properties can be annotated as pure. This annotation provides a signal to an optimizer that the expression does not have any potential side effects and is useful in cases where static analysis can not currently prove that there are, in fact, no side effects caused by the initializer.
PR Close#43064
The management of `browserUrlTree` currently has several problems with
correctly tracking the actual state of the browser.
This change makes the Router eagerly update the `browserUrlTree` when
handling navigations triggered by browser events (i.e., not 'imperative'). This
is because with those types of navigations, the browser URL bar is
_already_ updated. If we do not update the internal tracking of the
`browserUrlTree`, we will be out of sync with the real URL if the
navigation is rejected.
It would be best if we could remove `browserUrlTree` completely, but doing that
would require a lot more investigation and is blocked by #27059 because
the SpyLocation used in tests does not emulate real browser behavior.
fixes#43101
PR Close#43102
It is necessary in order to distinguish 2 different reasons for referencing the compiled-in locale.
1. Some code just needs to pass the locale value on to logic that actually uses it.
2. Other code uses the locale value to select locale-specific user-visible data and behavior.
Code modified by this change is of the first kind and should use `goog.getLocale()` in the future.
Note: there are still references to the `goog.LOCALE` in Angular codebase, but they are of second type.
PR Close#43089
Paul Gschwendtner