Due to the Windows Bazel directory structure, TypeScript can not safely
infer the return type of the `diagnose` function in the parallel worker
module. The return type should ideally be explicit regardless and so
a return type is now provided for the function.
By default Angular compilations will now use a Node.js Worker thread to load and execute the
TypeScript and Angular compilers when using esbuild-based builders (`application`/`browser-esbuild`).
This allows for longer synchronous actions such as semantic and template diagnostics to be calculated
in parallel to the other aspects of the application bundling process. The worker thread also has
a separate memory pool which significantly reduces the need for adjusting the main Node.js CLI process
memory settings with large application code sizes. This can be disabled via the `NG_BUILD_PARALLEL_TS`
environment variable currently to support performance benchmarking. However, this is an unsupported
environment variable option and may be removed in a future version.
When using an esbuild-based builder (`application` or `browser-esbuild`) with the development server,
a build that fails due to an TypeScript, Angular, or bundling error will now skip all output file result
processing. This avoids unnecessary work since an update of the client code will not take place. This
also allows for an error overlay to be displayed showing the first error available. The full list of
errors will still be shown in the console used to execute the `ng serve` command. Fixing the error will
automatically clear the error overlay but if there were multiple errors the next unfixed error will be
shown instead.
Previously, the application builder relied on TypeScript to detect affected component files via changes
to the internal template type check code. However, not all AOT compiler generated template errors will cause
the template type check code to be changed. Block syntax errors are one example. To ensure that component
diagnostics are recalculated when required, the component file will now always be considered affected when
a used template file is changed.
When using the application builder with Tailwind directives not in a directly referenced
Sass stylesheet, the Tailwind process was previously skipped. To avoid this problem, the
Tailwind keyword checks are now performed on the result of any stylesheet language processing
which will contain all the used stylesheet content.
When using the application builder with a Web Worker in watch mode, A change to the
Web Worker code will now invalidate the referencing source file to ensure that all changes
are captured and the new output file for the Web Worker is correctly injected into the
referencing output file. Previously, the Web Worker output file may have changed but the
reference may not have been updated causing an old instance of the Web worker code to be
used in watch mode.
Component style bundling when using the application builder will now only generate incremental contexts
when in watch mode. During non-watch build, this incremental context information is not needed and
unnecessarily increases memory usage during a build.
When using the application builder to create server builds for SSR and/or prerendering with localization
enabled, the locale data for each enabled locale is now properly included in the server output files.
While browser builds contain this data in the polyfills output file, the server builds do not contain a
polyfill output file, as a result, the locale data is added to the main server code instead. This is also
the case for other polyfill-like code including zone.js.
Any provided or required polyfills (the later mainly related to i18n) will now be bundled in a separate
concurrent bundling action. This has several benefits including allowing different bundling options
for the polyfills and minimizing rebundling of polyfills (which rarely change) in watch/serve mode.
Along with this change, the polyfill bundling options have been adjusted to not externalize packages
when in development server mode. This allows the zone.js globals to be more easily used as well as
minimizing the need for Vite to process a typically unchanging output file.
When using localization with the application builder for a large amount of locales, the number
of files that may need to be written to disk can become large. This may be problematic on certain
operating systems depending on the open file process limits. To avoid approaching the limit, the
number of concurrent writes is now limited to 64.
Within the application builder's template stylesheet processing, internal identifiers are used to track
the incremental bundling status of each inline stylesheet. This identifier now consists of the stylesheet
language, data, and containing file. This ensures that a tracking entry is maintained for each inline
stylesheet and allows for the full cleanup and any incremental bundling resources at the end of the build.
When a Less stylesheet is detected to require the deprecated `javascriptEnabled` Less option, the option
is enabled for the stylesheet and a warning is issued to inform the user of the behavior change. The
Less `javascriptEnabled` option has been deprecated and disabled by default since Less v3 (https://github.com/less/less.js/releases/tag/v3.0.0).
When enabled, the `javascriptEnabled` option allows JavaScript within Less stylesheets to be executed at build time.
Less option reference: https://lesscss.org/usage/#less-options
This provides similar behavior to the default Webpack-based build system. However, the Webpack-based build system
currently unconditionally enables the option.
Similar to the existing Webpack-based `browser` builder, the new `application` builder is also exported
from the `@angular-devkit/build-angular` package for use programmatically. As is the case for the existing
builder JavaScript exports from the package, the new export (`buildApplication`) is also considered experimental
and does not provide the support nor semver guarantees that the builders have when used via `angular.json` configuration.
The usage of the `plugins` parameter of the `buildApplication` allows adding esbuild compatible plugins to the end
of the plugin list for the main application code bundling. However, usage of the parameter may result in unexpected application
output and/or build failures. Stable and supported methods for build process extension are being evaluated for a future release.
The `browser-esbuild` builder now provides support for using the `deployUrl` option when building
applications. This option is still considered deprecated which is the same status as with the
Webpack-based `browser` application builder. This option is only available with the `browser-esbuild`
builder and not other esbuild-based builders. The `browser-esbuild` builder is primarily intended
to be used as a compatibility builder with the `browser` builder that requires only minimal changes
to use.
When using the esbuild-based builders (`application`/`browser-esbuild`), the localize polyfill and the locale specifier
for the configured source locale will now be injected into the application when available and the application is not
configured to inline translations (`localize` option disabled or otherwise not used). This is useful for when developing
a localized application with the development server or when the application is not translated but has a customized source
locale.
This commit improves the logic to block and share a TypeScript results across multiple esbuild instances (browser and server builds) which fixes an issue that previously during rebuilds in some cases did not block the build correctly.
When using the esbuild-based builders (`esbuild-browser`/`application`) in watch mode (including `ng serve`),
component stylesheets will now be incrementally rebuilt when needed. This avoids a full build of each
affected component's styles during an application rebuild. Both JIT and AOT mode are supported as well
as both inline and external styles.
The `anyComponentStyle` budget type is now supported when using bundle budgets in the esbuild-
based builders (`browser-esbuild`/`application`). The configuration and behavior are intended
to match that of the Webpack-based builder (`browser`). With this addition, the bundle budget
feature is now at feature parity with the Webpack-based builder.
The implementation of this budget type requires less code than the Webpack implementation due
to the component stylesheet information being present in the application's output metadata. This
removes the need for a custom budget plugin to extract the stylesheet size information during the build.
The bundle budget functionality (`budgets` option) is not available when using the esbuild-based
builders (`browser-esbuild`/`application`). The existing option format from the Webpack-based builder can
continue to be used. All budget types except `anyComponentStyle` are implemented. Any usage of the
`anyComponentStyle` type will be ignored when calculating budget failures. This type will be implemented
in a future change.
The previous Web Worker bundling code for the esbuild-based builders assumed that the first
output file was the JavaScript code for the worker. While this is typically the case, when
sourcemaps are enabled it may not be. To ensure the code file is used as the replacement path
for the Worker constructor, the output files are now searched for the code file.
This commit updates the application builder to output files in a standardized manner. The builder will output a `browser` directory for all the files that can be accessible by the browser, and a `server` directory that contains the SSR application. Both of these directories are created as children in the configured `outputPath`. Stats and license files will be outputted directly in the configured `outputPath`.
Example of output:
```
3rdpartylicenses.txt
├── browser
│ ├── chunk-2XJVAMHT.js
│ ├── favicon.ico
│ ├── index.html
│ ├── main-6JLMM7WW.js
│ ├── polyfills-4UVFGIFL.js
│ └── styles-5INURTSO.css
└── server
├── chunk-4ZCEIHD4.mjs
├── chunk-PMR7BAU4.mjs
├── chunk-TSP6W7K5.mjs
├── index.server.html
├── main.server.mjs
└── server.mjs
```
This commit removed the hard coded Node.js version in application builder server config and instead passes the Angular CLI supported Node.js versions that are currently stamped using Bazel.
Prior to this change when `baseUrl` was set to non-root or not set polyfills were not correctly resolved. Internally Esbuild uses the `baseUrl` to resolve non relative imports.
Closes: #25341
This adds the support of `namedChunks` for the new `application` builder.
It generates output like the following:
```
Initial Chunk Files | Names | Raw Size | Estimated Transfer Size
chunk-ACXUMF56.js | - | 94.14 kB | 28.25 kB
main-3WP5KDHR.js | main | 71.95 kB | 18.31 kB
polyfills-4UVFGIFL.js | polyfills | 32.85 kB | 10.68 kB
chunk-2XJVAMHT.js | - | 449 bytes | 449 bytes
styles-5INURTSO.css | styles | 0 bytes | 0 bytes
| Initial Total | 199.38 kB | 57.68 kB
Lazy Chunk Files | Names | Raw Size | Estimated Transfer Size
about.component-2PJOS5PM.js | - | 401 bytes | 401 bytes
home.component-25UHFOEY.js | - | 398 bytes | 398 bytes
```
This is really handy to get a glimpse at what a chunk is referring to and be able to analyze it (especially in applications with dozens of chunks).
When using the esbuild-based application build system through the `application` builder, the `localize`
option will now allow inlining project defined localizations when using the app shell, prerendering,
and service worker features. Previously a warning was issued and these features were disabled when the
`localize` option was enabled.
To prevent stale Angular template diagnostics from persisting in watch mode (including `ng serve`), the template
diagnostic cache will now be invalidated based on the set of changed external template files. This ensures that
the Angular AOT compiler will analyze the template again during the rebuild and clear any fixed errors.
This commit clean ups the compiled components state when the build is being executed in watch mode. This is required as otherwise during development `Component ID generation collision detected` are displayed on the server.
Closes: #25924
When using the esbuild-based builders (`application`/`browser`), Web Workers that use the supported
syntax will now be bundled. The bundling process currently uses an additional synchronous internal
esbuild execution. The execution must be synchronous due to the usage within a TypeScript transformer.
TypeScript's compilation process is fully synchronous. The bundling itself currently does not provide
all the features of the Webpack-based builder. The following limitations are present in the current
implementation but will be addressed in upcoming changes:
* Worker code is not type-checked
* Nested workers are not supported
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.
Some TypeScript files may previously have been emitted twice during builds when using the Angular compiler
esbuild plugin used within the esbuild-based browser application builder. It did not cause any build problems.
However, it may have caused builds to take longer than expected. This was caused by an incorrect comparison of the
transformed source file and the original source file found within the TypeScript program. Comparisons during
emit now compare only original source files which avoids the issue with the emitted files checks.
When using the esbuild-based builders (application/browser-esbuild), Web Workers following the previously
supported syntax as used in the Webpack-based builder will now be discovered. The worker entry points are not
yet bundled or otherwise processed. Currently, a warning will be issued to notify that the worker will not
be present in the built output.
Additional upcoming changes will add the processing and bundling support for the workers.
Web Worker syntax example: `new Worker(new URL('./my-worker-file', import.meta.url), { type: 'module' });`
This commit updates the routes extractor to use the newly exported private `ɵloadChildren` method from the router to executes a `route.loadChildren` callback and return an array of child routes.
See: https://github.com/angular/angular/pull/51818
This fixes an issue were routes could not be discovered automatically in a standalone application.
This is a total overhaul of the route extraction process as instead of using `guess-parser` NPM package, we now use the Angular Router. This enables a number of exciting possibilities for the future which were not possible before.
# How it works?
The application is bootstrapped and through DI injection we get the injector and router config instance and recursively build the routes tree.
The terser build time constant import from the `@angular/compiler-cli` package is no
longer used in the esbuild-based builder. The constants present are already defined
and conditionally added within the build configuration itself. This not only provides
more flexibility but also removes the need to import the package early in the process.
The import is also an expensive import due to it needing TypeScript and being ESM that
needs to be dynamically imported via a function helper to work around current ESM/TypeScript/CommonJS
limitations.
An upcoming change in Angular will allow `style` specified as strings, in addition to a new `styleUrl` property. These changes update the JIT resource transform to support the change.
Newer versions of the babel packages allow for removing some types packages as well as some helper
packages. The `@babel/template` package export used within the CLI is accessible from the `@babel/core`
package which allows removal of `@babel/template` as a direct dependency. Also, the `@babel/plugin-proposal-async-generator-functions`
package has been transitioned to `@babel/plugin-transform-async-generator-functions` due to async generators
being merged into the ECMAScript standard. Minor code cleanup based on the type cleanup was also performed
in the build optimizer babel passes.
Updates the logic that elides `setClassMetadata` calls to also elide `setClassMetadataAsync`. The latter will be emitted when the component uses the new `defer` block syntax.
Updates the logic for removing Angular metadata and pure top-level functions to account for arrow-function-based IIFEs. Currently Angular doesn't generate arrow functions, but it's being explored in https://github.com/angular/angular/pull/51637.
Version 0.19 of esbuild added the ability to consider tsconfig path mappings when using the
external packages build option. This addition allows the Angular build system to remove a
resolve plugin that previously was used to workaround this limitation. Removal of the plugin
may also provide improved rebuild performance when used with the development server as many
of the JavaScript resolution attempts will no longer need to be handled by the now removed
plugin.
When using the new developer preview application build system, Sass import/use usage that specifies
a package is adjusted to contain the resolve directory to workaround Sass import plugin limitations.
This resolve directory is now encoded to prevent the new specifier from looking like a URL with a
scheme to the Sass compiler. This can occur on Windows when a drive letter is present (`C:\`).
