Webpack-dev-server doesn't handle concurrency very well. When using port 0, and 2 processes start at the same time, they end up being given the same port. The main reason for the issue is that it find a free port, put only uses at a later stage.
This uses a dynamic import to load `@angular/compiler-cli` which may be ESM. CommonJS code can load ESM code via a dynamic import. Unfortunately, TypeScript will currently, unconditionally downlevel dynamic import into a require call. require calls cannot load ESM code and will result in a runtime error. To workaround this, a Function constructor is used to prevent TypeScript from changing the dynamic import. Once TypeScript provides support for keeping the dynamic import this workaround can be dropped and replaced with a standard dynamic import.
Partial Webpack configuration generators are used to create the various aspects of the final Webpack configuration for build, testing, and serving. They previously could only be synchronous but may need to perform asynchronous actions to setup the Webpack configuration in the future. This is particularly relevant as the CLI transitions from CommonJS to ESM wherein synchronous require calls need to be replaced with asynchronous dynamic imports. For dynamic imports to be successfully used the configuration generators need to support asynchronous operations.
The `@angular/compiler-cli` is used as a peer dependency and has the potential to not be present. As a result static imports should only be used for types and value imports should be dynamic so that they can be guarded in the event of package absence. There are still several instances of static imports for values but these will be corrected in follow-ups.
Polyfill related packages should not be downlevelled due to the nature of their code which may need to perform feature testing or leverage native capabilities to extract browser support information necessary to properly polyfill a given browser. In the case of `web-streams-polyfill`, it leverages the `%AsyncIteratorPrototype%`, when available, to fully polyfill its stream implementations. To access `%AsyncIteratorPrototype%`, a native async generator is needed and therefore the code present in the package cannot have this case of a native async generator downlevelled. `core-js` is also excluded for similar (and additional reasons).
The browser targets provided by `browserslist` have several differences than what `esbuild` expects for the Safari browsers. The first is that the iOS Safari is named `ios_saf` within browserslist and `ios` by esbuild. The former is now converted to the later when generating the target list for esbuild. The second difference is that `browserslist` supports a `TP` (Technology Preview) version for Safari but esbuild expects a numeric value for all versions. Since a TP version of Safari is assumed to be the latest unreleased version and as a result supports all currently known features, a high version number (999) is used as a replacement when generating the target list for esbuild.
BREAKING CHANGE:
The dev-server now uses WebSockets to communicate changes to the browser during HMR and live-reloaded. If during your development you are using a proxy you will need to enable proxying of WebSockets.
BREAKING CHANGE:
Support for `webpack-dev-server` version 3 has been removed. For more information about the migration please see: https://github.com/webpack/webpack-dev-server/blob/master/migration-v4.md
Note: this change only affects users depending on `@angular-devkit/build-webpack` directly.
rules_nodejs 4 requires that a package_name property be specified within a ts_library rule for the output to be linked into the package repository. Failing to add the property can cause test failures due to unresolved packages.
The `no-useless-escape` eslint rule has now been enabled which removes unneeded characters and complexity from string literals and regular expressions. All files that were in violation of this rule have also been corrected.
This PR adds UpdateBuffer2 which should eventually
replace UpdateBuffer. UpdateBuffer2 internally uses
the magic-string library.
UpdateBuffer and related symbols have been marked
as deprecated.
Closes#21110
With this change we provide the list of supported browsers to Esbuild during CSS optimizations, so it can perform optimizations based on the browser support needed.
Closes#21594
When using custom builders, it is possible to remove entries from the webpack-configuration
manually. This may eventually lead to undefined entryPoints in async-chunks.ts and aborts
the compilation.
Application code (TS files) will only contain native async if the TypeScript configuration target is ES2017+. However, third-party libraries can contain native async regardless of the target option. To address these third-party libraries, all non-application files need to be analyzed to determine if they must have native async downlevelled. The analysis is first resource path based and then a string match search for the async keyword. This approach has the potential for rare false positives (for example, the word async in a comment) but the outcome would only be a small amount of additional processing for that one file due to the no-op transformation. This is in contrast to a more exact method covering those rare false positives but that would require a more expensive analysis operation on every file and result in longer overall build times.
`esbuild` and `terser` are now used to optimize global scripts in addition to the previous performance enhancement of optimizing application bundles. This change removes the need for the `terser-webpack-plugin` as a direct dependency and provides further production build time improvements for applications which use global scripts (`scripts` option in the `angular.json` file).
Since `esbuild` does not support optimizing a script with ES2015+ syntax when targetting ES5, the JavaScript optimizer will fallback to only using terser in the event that such a situation occurs. This will only happen if ES5 is the output target for an application and a global script contains ES2015+ syntax. In that case, the global script is technically already invalid for the target environment and may fail at runtime but this is and has been considered a configuration issue. Global scripts must be compatible with the target environment/browsers.
The `getEsVersionForFileName` helper function was previously used for recently removed differential loading support but is now unused and can also be removed.
