This commit adds support in the Angular monorepo and in the Angular
compiler(s) for TypeScript 3.8. All packages can now compile with
TS 3.8.
For most of the repo, only a handful few typings adjustments were needed:
* TS 3.8 has a new `CustomElementConstructor` DOM type, which enforces a
zero-argument constructor. The `NgElementConstructor` type previously
declared a required `injector` argument despite the fact that its
implementation allowed `injector` to be optional. The interface type was
updated to reflect the optionality of the argument.
* Certain error messages were changed, and expectations in tests were
updated as a result.
* tsserver (part of language server) now returns performance information in
responses, so test expectations were changed to only assert on the actual
body content of responses.
For compiler-cli and schematics (which use the TypeScript AST) a major
breaking change was the introduction of the export form:
```typescript
export * as foo from 'bar';
```
This is a `ts.NamespaceExport`, and the `exportClause` of a
`ts.ExportDeclaration` can now take this type as well as `ts.NamedExports`.
This broke a lot of places where `exportClause` was assumed to be
`ts.NamedExports`.
For the most part these breakages were in cases where it is not necessary
to handle the new `ts.NamedExports` anyway. ngtsc's design uses the
`ts.TypeChecker` APIs to understand syntax and so automatically supports the
new form of exports.
The View Engine compiler on the other hand extracts TS structures into
metadata.json files, and that format was not designed for namespaced
exports. As a result it will take a nontrivial amount of work if we want to
support such exports in View Engine. For now, these new exports are not
accounted for in metadata.json, and so using them in "folded" Angular
expressions will result in errors (probably claiming that the referenced
exported namespace doesn't exist).
Care was taken to only use TS APIs which are present in 3.7/3.6, as Angular
needs to remain compatible with these for the time being.
This commit does not update angular.io.
PR Close#35864
The options for `flatModuleId` and `flatModuleOutFile` had been removed in the CLI
from generated libraries with 718ee15b9a.
This has been done because `ng-packagr` (which is used to build the
libraries) automatically set these options in-memory when it compiles the library.
No migration has been created for this because there was no actual need to get rid of
this. Keeping the options in the library `tsconfig` does not cause any problems unless
the `tsconfig` is used outside of `ng-packagr`. This was not anticipated, but is now
commonly done in `ng update` migrations.
The `ng update` migrations try to create an instance of the `AngularCompilerProgram` by
simply parsing the `tsconfig`. The migrations make the valid assumption that `tsconfig` files
are not incomplete/invalid. They _definitely_ are in the file system though. It just works for
libraries because `ng-packagr` in-memory completes the invalid `tsconfig` files, so that they
can be passed to the `@angular/compiler-cli`.
We can't have this logic in the `ng update` migrations because it's
out-of-scope for individual migrations to distinguish between libraries
and applications. Also it would be out-of-scope to parse the
`ng-packagr` configuration and handle the tsconfig in-memory completion.
As a workaround though, we can remove the flat-module bundle options
in-memory when creating the compiler program. This is acceptable since
we don't emit the program and the flat module bundles are not needed.
Fixes#34985.
PR Close#35824
Previously, the compiler performed an incremental build by analyzing and
resolving all classes in the program (even unchanged ones) and then using
the dependency graph information to determine which .js files were stale and
needed to be re-emitted. This algorithm produced "correct" rebuilds, but the
cost of re-analyzing the entire program turned out to be higher than
anticipated, especially for component-heavy compilations.
To achieve performant rebuilds, it is necessary to reuse previous analysis
results if possible. Doing this safely requires knowing when prior work is
viable and when it is stale and needs to be re-done.
The new algorithm implemented by this commit is such:
1) Each incremental build starts with knowledge of the last known good
dependency graph and analysis results from the last successful build,
plus of course information about the set of files changed.
2) The previous dependency graph's information is used to determine the
set of source files which have "logically" changed. A source file is
considered logically changed if it or any of its dependencies have
physically changed (on disk) since the last successful compilation. Any
logically unchanged dependencies have their dependency information copied
over to the new dependency graph.
3) During the `TraitCompiler`'s loop to consider all source files in the
program, if a source file is logically unchanged then its previous
analyses are "adopted" (and their 'register' steps are run). If the file
is logically changed, then it is re-analyzed as usual.
4) Then, incremental build proceeds as before, with the new dependency graph
being used to determine the set of files which require re-emitting.
This analysis reuse avoids template parsing operations in many circumstances
and significantly reduces the time it takes ngtsc to rebuild a large
application.
Future work will increase performance even more, by tackling a variety of
other opportunities to reuse or avoid work.
PR Close#34288
With Angular CLI version 9 RC 3 we can run a single migration for a package using the name of the migration schematic.
We need to pass the schematic name as a value to the `migrate-only` option.
Ex:
```
ng update @angular/core --migrate-only migration-v9-undecorated-classes-with-di
```
See: https://github.com/angular/angular-cli/pull/16174
PR Close#33958
Currently TypeScript projects with an invalid tsconfig configuration,
cause the undecorated-classes-with-di migration to throw. Instead we
should gracefully exit the migration (like we do for syntactical
diagnostics), but report that there are configuration issues.
This issue surfaced when testing this migration in combination
with the Angular CLI migrations. One of the CLI migrations currently
causes invalid tsconfig files which then cause this issue in the
undecorated-classes-with-di migration.
PR Close#33567
Currently if one of the project targets could not be analyzed
due to AOT compiler program failures, we gracefully proceed
with the migration. This is expected, but we should not
print a message at the end of the migration that the migration
was _successful_. The migration was only done partially, hence
it's potentially incomplete and we should make it clear that once
the failures are resolved, the migration should be re-run.
PR Close#33315
With the next version of the CLI we don't need to add logging for the description of the schematic as part of the schematic itself.
This is because now, the CLI will print the description defined in the `migrations.json` file.
See: https://github.com/angular/angular-cli/pull/15951
PR Close#33440
Angular v9 schematics should print out a link to the migration
guide associated with each schematic. This way, users have an
easy way to find more information about the automatic code
transformations they will see with `ng update`.
PR Close#33258
Current we need to create and override certain compiler host methods in every schematic because schematics use a virtual fs. We this change we extract this logic to a common util.
PR Close#32827
The creation of StaticReflector in createMetadataResolver() is a very expensive operation because it involves numerous module resolutions.
To make matter worse, since the API of the Reflector does not provide the ability to invalidate its internal caches, it has to be destroyed and recreated on *every* program change.
This has a HUGE impact on performance.
This PR fixes this problem by carefully invalidating all StaticSymbols in a file that has changed, thereby reducing the overhead of recomputation on program change.
PR Close#32543
Currently the undecorated-classes-with-di migration leverages NGC in order
to work with metadata resolution. Since NGC by default tries to resolve referenced
resources on initialization of the underlying TS program, it can result in unexpected
migration failures due to missing resource files.
This is especially an issue since the CLI wraps the `AngularCompilerProgram` with
special logic (i.e. to support SCSS preprocessing etc.). We don't have all of this since
we instantiate a vanilla NGC program.
The solution to the problem is to simply treat resource requests as valid, and returning
a fake content. The migration is not dependent on templates or stylesheets.. so it's the
simplest and most robust solution.
Fixes#32826
PR Close#32953
Currently the undecorated classes migration decorates base classes if no
explicit constructor is defined on all classes in the inheritance chain.
We only want to decorate base classes which define a constructor that is
inherited. Additionally for best practice, all classes in between the class
that inherits the constructor and the one that defines it are also decorated.
PR Close#32319
The `undecorated-classes-with-di` migration currently creates invalid object literals from parsed
NGC metadata files if there are object literal properties with keys that contain special characters.
e.g. consider a decorated base class with a host binding using `[class.X]`. Currently the migration
parses and converts the metadata to TypeScript code but incorrectly uses `[class.X]` unquoted as
identifier.
PR Close#32319
ec4381dd40 enabled Ivy by default. This is
problematic as migrations like `undecorated-classes-with-di` depend on the
`AngularCompilerProgram` (NGC) in order to perform the migration from
version 8 to version 9. In order to ensure that the migration always runs
with NGC (and doesn't get the `NgtscProgram`), we need to explicitly disable
ivy when creating the `@angular/compiler-cli` program for the migration.
PR Close#32318
Introduces a new migration schematic that follows the given
migration plan: https://hackmd.io/@alx/S1XKqMZeS.
First case: The schematic detects decorated directives which
inherit a constructor. The migration ensures that all base
classes until the class with the explicit constructor are
properly decorated with "@Directive()" or "@Component". In
case one of these classes is not decorated, the schematic
adds the abstract "@Directive()" decorator automatically.
Second case: The schematic detects undecorated declarations
and copies the inherited "@Directive()", "@Component" or
"@Pipe" decorator to the undecorated derived class. This
involves non-trivial import rewriting, identifier aliasing
and AOT metadata serializing
(as decorators are not always part of source files)
PR Close#31650
Alex Rickabaugh
Paul Gschwendtner
Alan Agius
Michael Prentice
Kara Erickson
Alan
Keen Yee Liau