Ivy-only Webpack Compiler Plugin #17717
Conversation
clydin
force-pushed
the
webpack-ngtsc-plugin
branch
2 times, most recently
from
3e07920 to
29db8d1
Compare
clydin
force-pushed
the
webpack-ngtsc-plugin
branch
2 times, most recently
from
3178e4f to
054af80
Compare
clydin
force-pushed
the
webpack-ngtsc-plugin
branch
4 times, most recently
from
09f9243 to
a38b1f9
Compare
clydin
force-pushed
the
webpack-ngtsc-plugin
branch
3 times, most recently
from
91d71d4 to
4c4fc6a
Compare
clydin
force-pushed
the
webpack-ngtsc-plugin
branch
10 times, most recently
from
df0024d to
25714a6
Compare
clydin
force-pushed
the
webpack-ngtsc-plugin
branch
3 times, most recently
from
e31511d to
e04e781
Compare
clydin
force-pushed
the
webpack-ngtsc-plugin
branch
2 times, most recently
from
c48f99a to
8667fd7
Compare
alan-agius4
added
action: merge
clydin
force-pushed
the
webpack-ngtsc-plugin
branch
2 times, most recently
from
b1db758 to
bc6fde6
Compare
clydin
force-pushed
the
webpack-ngtsc-plugin
branch
11 times, most recently
from
e348a46 to
0c78d5a
Compare
|
|
||
| // Save for next rebuild | ||
| if (this.watchMode) { | ||
| this.ngtscNextProgram = ngtsc.getNextProgram(); |
There was a problem hiding this comment.
Requesting the next program here might be premature, as requesting type check diagnostics (NgtscPlugin.getDiagnostics) will create a new ts.Program which provides a new next program to use for the next incremental build. I verified that calling NgtscPlugin.getNextProgram just before calling this.createFileEmitter in the promise handler does indeed return a different ts.Program.
There was a problem hiding this comment.
This was originally later in the process. As an experimental with the release of TS 4.0, I moved it to its current location and it didn't appear to cause a change in behavior (no crashes, diagnostics appear to be the same, etc.). TS 4.0 removed an unnecessary assert statement that would previously cause an exception in this case (https://github.com/microsoft/TypeScript/blob/v3.9.2/src/compiler/program.ts#L1239).
There was a problem hiding this comment.
Yeah I also didn't observe any difference in behavior. I was expecting it to crash due to that assertion, but if it's been removed then surely it does not. I'm not sure if this causes extra memory to be retained, and what the size of a reused ts.Program would be. Maybe @alxhub has some more insights here.
packages/angular_devkit/build_angular/src/webpack/configs/typescript.ts
Outdated
Show resolved
Hide resolved
This change introduces a new Ivy-only Webpack plugin. The plugin is based on the design introduced by `tsc_wrapped` within Bazel’s `rules_typescript` and leverages the newly added ngtsc plugin from within the `@angular/compiler-cli` package. By leveraging the same plugin interface that it used by Bazel, a common interface can be used to access the Angular compiler. This has benefits to both major build systems and dramatically reduces the necessary code infrastructure to integrate the Angular compiler. The plugin also simplifies and reduces the amount of code within the plugin by leveraging newer TypeScript features and capabilities. The need for the virtual filesystem has also been removed. The file replacements capability was the primary driver for the previous need for the virtual filesystem. File replacements are now implemented using a two-pronged approach. The first, for TypeScript, is to hook TypeScript module resolution and adjust the resolved modules based on the configured file replacements. This is similar in behavior to TypeScript path mapping. The second, for Webpack, is the use of the `NormalModuleReplacementPlugin` to facilitate bundling of the configured file replacements. An advantage to this approach is that the build system (both TypeScript and Webpack) are now aware of the replacements and can operate without augmenting multiple aspects of system as was needed previously. The plugin also introduces the use of TypeScript’s builder programs. The current primary benefit is more accurate and simplified dependency discovery. Further, they also provide for the potential future introduction of incremental build support and incremental type checking. NOTE: The deprecated string format for lazy routes is not supported by this plugin. Dynamic imports are recommended for use with Ivy and are required when using the new plugin.
…at tests The new Ivy-only Webpack plugin no longer supports the deprecate string format for lazy routes.
…ions This change allows the compiler options used by the TypeScript paths plugin to be updated if the TypeScript configuration file is changed during a rebuild.
…feature flag The new Ivy Webpack plugin is considered experimental and can only be used by enabling the `NG_BUILD_IVY_EXPERIMENTAL` environment variable.
clydin
force-pushed
the
webpack-ngtsc-plugin
branch
from
0c78d5a to
409c5d3
Compare
clydin
changed the title
|
Is it available as a beta API though? Can I just replace |
|
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
This change introduces a new Ivy-only Webpack compiler plugin. The plugin is based on and leverages the Ivy ngtsc APIs from within the
@angular/compiler-clipackage. The plugin also simplifies and reduces the amount of code within the plugin by leveraging newer TypeScript features and capabilities. The need for the virtual filesystem has also been removed. The file replacements capability was the primary driver for the previous need for the virtual filesystem. File replacements are now implemented using a two-pronged approach. The first, for TypeScript, is to hook TypeScript module resolution and adjust the resolved modules based on the configured file replacements. This is similar in behavior to TypeScript path mapping. The second, for Webpack, is the use of theNormalModuleReplacementPluginto facilitate bundling of the configured file replacements. An advantage to this approach is that the build system (both TypeScript and Webpack) are now aware of the replacements and can operate without augmenting multiple aspects of system as was needed previously.The plugin also introduces the use of TypeScript’s builder programs. The current primary benefit is more accurate and simplified dependency discovery. Further, they also provide for the introduction of incremental build support and incremental type checking.
NOTE: The deprecated string format for lazy routes is not supported by this plugin. Dynamic imports are recommended for use with Ivy and are required when using the new plugin.
Performance and memory usage have also been improved with these changes. Initial benchmarking indicates an average ~10% reduction in production build time and a similar ~10% reduction in peak memory usage. Watch mode (including the development server) no longer requires the forked type checker which provides a ~30% improvement in memory usage for typical development scenarios. The plugin is also not yet fully optimized. The next phase of development will introduce performance tracing and support further improvements.