74edde0a94
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 |
||
|---|---|---|
| .. | ||
| BUILD.bazel | ||
| README.md | ||
| collector.ts | ||
| index.ts | ||
| transform.ts | ||
| util.ts | ||
README.md
ModuleWithProviders migration
ModuleWithProviders type will not default to the any type for its generic in a future version of Angular.
This migration adds a generic to any ModuleWithProvider types found.
Before
import { NgModule, ModuleWithProviders } from '@angular/core';
@NgModule({})
export class MyModule {
static forRoot(): ModuleWithProviders {
ngModule: MyModule
}
}
After
import { NgModule, ModuleWithProviders } from '@angular/core';
@NgModule({})
export class MyModule {
static forRoot(): ModuleWithProviders<MyModule> {
ngModule: MyModule
}
}