deacc741e0
`NgCompiler` previously had a notion of the "next" `ts.Program`, which served two purposes: * it allowed a client using the `ts.createProgram` API to query for the latest program produced by the previous `NgCompiler`, as a starting point for building the _next_ program that incorporated any new user changes. * it allowed the old `NgCompiler` to be queried for the `ts.Program` on which all prior state is based, which is needed to compute the delta from the new program to ultimately determine how much of the prior state can be reused. This system contained a flaw: it relied on the `NgCompiler` knowing when the `ts.Program` would be changed. This works fine for changes that originate in `NgCompiler` APIs, but a client of the `TemplateTypeChecker` may use that API in ways that create new `ts.Program`s without the `NgCompiler`'s knowledge. This caused the `NgCompiler`'s concept of the "next" program to get out of sync, causing incorrectness in future incremental analysis. This refactoring cleans up the compiler's `ts.Program` management in several ways: * `TypeCheckingProgramStrategy`, the API which controls `ts.Program` updating, is renamed to the `ProgramDriver` and extracted to a separate ngtsc package. * It loses its responsibility of determining component shim filenames. That functionality now lives exclusively in the template type-checking package. * The "next" `ts.Program` concept is renamed to the "current" program, as the "next" name was misleading in several ways. * `NgCompiler` now wraps the `ProgramDriver` used in the `TemplateTypeChecker` to know when a new `ts.Program` is created, regardless of which API drove the creation, which actually fixes the bug. PR Close #41291
2.5 KiB
The Program Driver interface
ProgramDriver is a small but important interface which allows the template type-checking machinery to request changes to the current ts.Program, and to receive a new ts.Program with those changes applied. This is used to add template type-checking code to the current ts.Program, eventually allowing for diagnostics to be produced within that code. This operation is abstracted behind this interface because different clients create ts.Programs differently. The Language Service, for example, creates ts.Programs from the current editor state on request, while the TS compiler API creates them explicitly.
When running using the TS APIs, it's important that each new ts.Program be created incrementally from the previous ts.Program. Under a normal compilation, this means that programs alternate between template type checking programs and user programs:
ts.Program#1is created from user input (the user's source files).ts.Program#2is created incrementally on top of #1 for template type-checking, and adds private TCB code.ts.Program#3is created incrementally on top of #2 when the user makes changes to files on disk (incremental build).ts.Program#4is created incrementally on top of #3 to adjust template type-checking code according to the user's changes.
The TsCreateProgramDriver performs this operation for template type-checking ts.Programs built by the command-line compiler or by the CLI. The latest template type-checking program is then exposed via the NgCompiler's getCurrentProgram() operation, and new user programs are expected to be created incrementally on top of the previous template type-checking program.
Programs and the compiler as a service
Not all clients of the compiler follow the incremental tick-tock scenario above. When the compiler is used as a service, new ts.Programs may be generated in response to various queries, either directly to NgCompiler or via the TemplateTypeChecker. Internally, the compiler will use the current ProgramDriver to create these additional ts.Programs as needed.
Incremental builds (new user code changes) may also require changing the ts.Program, using the compiler's incremental ticket process. If the TsCreateProgramDriver is used, the client is responsible for ensuring that any new incremental ts.Programs are created on top of the current program from the previous compilation, which can be obtained via NgCompiler's getCurrentProgram().