Any errors or warnings generated from post-bundling steps of the build will now be formatted and displayed
in a similar manner to the bundling errors and warnings. This should be most noticeable with bundle budgets.
This is to better match the nature of the application builder where the target can be both browser and server.
DEPRECATED: The `browserTarget` in the dev-server and extract-i18n builders have been deprecated in favor of `buildTarget`.
When using the esbuild-based application build system through either the `application`
or `browser-esbuild` builder, the `localize` option will now allow inlining project
defined localizations. The process to configure and enable the i18n system is the same
as with the Webpack-based `browser` builder. The implementation uses a similar approach
to the `browser` builder in which the application is built once and then post-processed
for each active locale. In addition to inlining translations, the locale identifier is
injected and the locale specific data is added to the applications. Currently, this
implementation adds all the locale specific data to each application during the initial
building. While this may cause a small increase in the polyfills bundle (locale data is
very small in size), it has a benefit of faster builds and a significantly less complicated
build process. Additional size optimizations to the data itself are also being
considered to even further reduce impact. Also, with the eventual shift towards the standard
`Intl` web APIs, the need for the locale data will become obsolete in addition to the build
time code necessary to add it to the application.
While build capabilities are functional, there are several areas which have not yet been
fully implemented but will be in future changes. These include console progress information,
efficient watch support, and app-shell/service worker support.
The `ng extract-i18n` command now supports using either the developer preview esbuild-based browser
or application builders. Support for the existing Webpack-based build system has been maintained.
The extraction process will now build the application based on the build target defined builder in
the case of either `@angular-devkit/build-angular:browser-esbuild` and `@angular-devkit/build-angular:application`.
In the case of the application builder, SSR output code generation is disabled to prevent duplicate messages
for the same underlying source code.
The `extract-i18n` builder code has been restructured in a similar fashion to the `dev-server` builder.
This refactor provides the groundwork to add support for the `application` and `browser-esbuild` builders
during message extraction.
The webpack related logic has been split into a separate file and is dynamically imported when needed.
Additionally the options processing has been moved to a separate file and the `index.ts` now only exports
instead of previously containing most of the builder logic.
G3 is now using RXJS version 7 which makes it possible for the CLI to also be updated to RXJS 7.
NB: this change does not remove all usages of the deprecated APIs.
Closes#24371
The usage of Stylus in the CLI is minimal and this package never reached version 1.
BREAKING CHANGE:
Deprecated support for Stylus has been removed. The Stylus package has never reached a stable version and its usage in the Angular CLI is minimal. It's recommended to migrate to another CSS preprocessor that the Angular CLI supports.
The use of the `@angular-devkit/core` `JsonObject` type is no longer needed to satisfy the type requirements of `@angular-devkit/architect` package builder creation functions.
With every build-angular release, previously created cache entries get stale and are no longer used. This causes the cache to keep growing as older files are not purged.
With this change we automatically purge entries that have been created with older version of build-angular and can no longer be used with the current installed version.
Closes#22323
* fix(@angular-devkit/build-angular): correctly extract messages when using cached build
Extracted messages are not part of Webpack pipeline and hence they cannot be retrieved from cache. Therefore, we need to mark the extraction loader as non cacheable.
Closes#22264
* fixup! fix(@angular-devkit/build-angular): correctly extract messages when using cached build
With this change we unify most of the webpack configuration into the common configuration. A number of lengthy functions and code portions have been moved into a seperate file to make the configuration easier to follow.
The regular expressions based checks for TypeScript and JavaScript files used by Webpack module rules have been updated to include all current extension variations.
JavaScript files can be either `.js`, `.mjs`, or `.cjs`. TypeScript files as of the upcoming version 4.5 can be either `.ts`, `.mts`, or `.cts`.
Also while not officially supported by Angular, the TypeScript compiler can attempt to process any of the previous extensions with an `x` suffix which indicates a JSX/TSX file.
With the Angular CLI currently being a CommonJS package, this change uses a dynamic import to load `@angular/localize` 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.
The architect runtime no longer requires builder options to include the JsonObject in its type definition when calling `createBuilder`. The remaining cases in this package have been removed.
Applications can now only be built with Ivy. However, several checks were still present in the code to determine if Ivy was enabled. Since Ivy is always enabled these checks have since become unused code and can be removed.
All Angular builders are now located within one subdirectory of the `src` directory. This organization provides better discovery of the builders and will allow builder specific code to be stored in a single area.
