The AOT compiler's internal template type-checking files are not intended to be directly analyzed for diagnostics by the emitting program and are instead analyzed during the template type-checking phase. Previously, only semantic diagnostics were ignored. Now both syntactic and semantic diagnostics are ignored. This change prevents non-actionable diagnostics from being shown during a build.
Addresses: https://github.com/angular/angular/issues/42667
The Angular Webpack loader will now access the Angular Webpack Plugin's file emitters via the loader context directly. This is instead of using the not fully public Webpack compilation property on the loader context. This change also removes the need to directly alter the Webpack compilation object which previously added an additional property.
The ngcc resolver must be synchronous to integrate with TypeScript which is only synchronous. If the Webpack resolver cache option is enabled when creating a resolver, the resolver will become asynchronous after a rebuild due to the internal implementation of the resolver caching. To prevent this change in behavior, caching is disabled for the ngcc resolver. The ngcc resolver is only used the first time each dependency is used by the application.
Webpack 5 provides the Webpack instance as a property on the Webpack compiler which allows Webpack plugins to leverage the same Webpack instance that was used to initiate the build. The `AngularWebpackPlugin` now will only use the provided instance to ensure that differing Webpack instances and/or versions are not used.
By using the Webpack compiler to request a resolver, configuration supplied options will automatically be used (such as symlinks) and also ensures that the same version of the resolver code will be used. Additionally, this removes one of the reasons to directly depend on the `enhanced-resolve` package.
This caused Webpack to mark all TypeScript files as removed after the first compilation on Windows because the file separators didn't match
Closes#20891
Webpack provides a method to construct a special request string that will remap a loader chain to appear to be from a specific resource path. This requires a custom loader, however, it allows rule matching to leverage the existing file extension based approach and allows providing a path to other loaders which simplifies relative request handling.
When not in a watch mode, the analyis performed by TypeScript to improve incremental type checking can be avoided by creating an abstract builder program that only wraps the underlying TypeScript program.
Performance enhancements in the upcoming TypeScript 4.3 may remove the need for this. However, TypeScript 4.3 is not yet released and is not yet supported. In addition, TypeScript 4.2 will continue to be supported throughout the v12 major even when TypeScript 4.3 is also supported.
During a build, the number of iterations over both the TypeScript program's source files and Webpack's modules has been reduced. Both of these collections can contain a significant number of elements especially in larger applications.
This change adjusts the Angular required files rebuilding logic to not block on each individual file's Webpack module rebuild. Now all required Webpack modules are discovered then rebuilt asynchrounously and only blocked on the full list of rebuilds. The promise-based Webpack rebuild function is also now only created if a rebuild is required.
All TypeScript files have been updated to pass the new eslint-based linting checks. eslint compatible disabling comments have also been added in place of the previous tslint comments.
Webpack 5 directly provides the set of modified and removed files. This feature allows for the removal of the file timestamp logic within the plugin that was previously used to generated the set of changed files on a rebuild.
When in watch mode, both the file and inline resources will now be cached between rebuilds. This removes the need to reprocess inline resources that have not changed even if the containing TypeScript file has changed.
This change makes several changes to attempt to reduce retained memory within the resource loader. The first is the preemptive clearing of the resource loader's parent compilation after all modules are built. The second removes the cached sourcemaps for each resource which are not yet used by the system. And finally, the child compilations are no longer stored on the parent compilation and instead the dependencies, errors, and warnings are propagated to the parent compilation.
This change updates the Angular Webpack Plugin's resource loader to support processing styles that do not exist on disk when the `inlineStyleMimeType` option is used.
This change adds the new `inlineStyleMimeType` option. When set to a valid MIME type, enables conversion of an Angular Component's inline styles into data URIs. This allows a Webpack 5 configuration rule to use the `mimetype` condition to process the inline styles. A valid MIME type is a string starting with `text/` (Example for CSS: `text/css`).
This change allows multiple instances of the `AngularWebpackPlugin` to be present in a Webpack configuration.
Each plugin instance should reference a different TypeScript configuration file (`tsconfig.json`) and the TypeScript configuration files should be setup to not include source files present in the other TypeScript configuration files. If files are included in more than one TypeScript configuration, the first plugin present in the Webpack configuration that can emit the file will be used.
Closes: #5072
BREAKING CHANGE: Removal of View Engine support from application builds
With the removal of the deprecated View Engine compiler in Angular version 12 for applications, the View Engine Webpack plugin has been removed.
The Ivy-based Webpack plugin is the default used within the Angular CLI.
If using a custom standalone Webpack configuration, the removed `AngularCompilerPlugin` should be replaced with the Ivy-based `AngularWebpackPlugin`.
This change improves the performance of incremental type checking of Angular templates by reducing the number of calls to retrieve the diagnostics.
Only the set of affected files will be queried on a rebuild. The affected set includes files TypeScript deems affected, files that
are required to be emitted by the Angular compiler, and the original file for any TTC shim file that TypeScript deems affected.
BREAKING CHANGE
`suppressZoneJsIncompatibilityWarning` option has been removed. If you are using this plugin directly and `async/await` in ES2017 make sure you downlevel the async syntax using Babel.
See: https://github.com/angular/zone.js/pull/1140 for more information.
This change uses the newly introduced precalculated file dependencies for each TypeScript file instead of querying TypeScript for the SourceFile's dependencies when performing the unused file check at the end of the build cycle. This change removes the need to recalculate the dependencies for each TypeScript file present in the Webpack compilation.
This change augments a TypeScript Compiler Host's resolveModuleNames function to collect dependencies of the containing file based on the module names passed to the resolveModuleNames function. This process assumes that consumers of the Compiler Host will call resolveModuleNames with modules that are actually present in a containing file. The TypeScript compiler exhibits such behavior making this process effective at generating a set of all direct dependencies for a given source file.
This process is a workaround for gathering a TypeScript SourceFile's dependencies as there is no currently exposed public method to do so. A BuilderProgram does have a `getAllDependencies` function. However, that function returns all transitive dependencies as well which can cause excessive Webpack rebuilds especially in larger programs.
BREAKING CHANGE:
With this change we drop support for string based lazy loading `./lazy.module#LazyModule` use dynamic imports instead.
The following options which were used to support the above syntax were removed without replacement.
- discoverLazyRoutes
- additionalLazyModules
- additionalLazyModuleResources
- contextElementDependencyConstructor
This change reduces the number of different Webpack resolver factory hooks required to initialize the compiler plugins.
Webpack 5 also requires the path plugin to be configured earlier in the process and the options hook provides that ability.
The `@ngtools/webpack` package now officially supports Webpack 5.
It is also now built against Webpack 5 types. Webpack 4 support is temporarily maintained while the remainder of the tooling is transitioned.
This change adds additional checks to reduce the number of Webpack `rebuildModule` calls when the Angular compiler requests additional files to be rebuilt. Now if an emitted file's output does not change from its previous emit, a Webpack rebuild of the module is not performed. This can greatly reduce the amount of computation needed during a rebuild as any files that required re-analysis by the Angular compiler but whose final output did not change will not trigger potential expensive Webpack module graph analysis and additonal module rebuilds.
With this change we add a new `jitMode` option to the ivy AngularWebpackPlugin.
`readConfiguration` from `@angular/compiler-cli` will use file configuration options over programmaticly supplied options. By using a separate option the options precedence issue can be avoided.
Closes#19949
With this change we replace `getDiagnostics` with `getDiagnosticsForFile`. `getDiagnostics` no longer accept a parameter and is intended to be used instead of `getDiagnostics`.
I used `OptimizeFor.WholeProgram` based on the comments in https://github.com/angular/angular/pull/40331#discussion_r555953776 which suggests that if you iterate through files one at a time the `WholeProgram` flag should be used.
For more context see: https://github.com/angular/angular/pull/40331
The `fileTimestamps` property on the Webpack compilation object no longer exists with Webpack 5. This change uses the Webpack compiler's property of the same name instead. The cache invalidation is also moved to a separate file and now calculates the changed file set as well. This eliminates the second iteration of the file timestamps within the resource loader.
A cached path normalization helper is now used in places that still require normalization. Usage was also removed completely in locations that are not needed either because the path was later normalized or the normalization would provide no benefit.
The `Compilation.compilationDependencies` property is now deprecated in Webpack 5. The `Compilation.fileDependencies` property is now used instead with Webpack 5.
Use `enhanced-resolve` instead of `require.resolve` to ensure that we can use symlink path instead of real-path when resolving a linked module.
Closes#19395
This change introduces a new Ivy Webpack compiler plugin. The plugin leverages the Ivy APIs from the @angular/compiler-cli package. 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 introduction of incremental build support and incremental type checking.
