The previously unused `reuseResults` option for the JavaScript transformer used by the
`application` builder has been removed and replaced with an optional cache option. This
option is currently unused by will allow the caching of JavaScript transformations including
the Angular linker.
Several parts of application builder use slightly different variants of an in-memory
cache. To avoid duplication of code, unified cache infrastructure is now available for
use internally. This also allows for expanded use in other areas of the build system
including the future potential for adding additional backing cache stores.
To ensure that Vite does not unintentionally attempt to prebundle a module that was explicitly
marked as external (typically via the `externalDependencies` build option), the full list of
externalized imports is now filtered by the dependencies specified within the external configuration.
Vite currently will include a module for prebundling if it is present in the include list even though
it may also be present in the exclude list.
This commits, changes the behaviour in the esbuild based builders by emitting component sourcemaps in external files instead of inlining them.
Closes#24049 and closes#26676
When processing a Web Worker reference in application code, the Web Worker entry point is bundled
in a separate action. The external dependencies configuration was previously not passed on to this
action which caused the Web Worker bundling to attempt to bundle any configured external dependencies.
This could lead to build errors if the dependency does not exist within the project.
Experimental programmatically added build extensions are now passed to the internal application builder
when used with the development server. Previously, the plugins were not passed in a manner that would
allow them to be used if the `application` builder was selected as the builder for dev server usage.
The metadata used by the development server to determine the prebundling and externalization behavior
is now created using the external configurations of each bundling operation context directly instead
of the higher level `externalDependencies` build option. This better captures the explicitly defined
external values as each bundling operation configuration could contain additional values based on
the needs and/or customization of each. This will have no current noticeable behavior change as the
default behavior currently does not differ from the higher level option.
The promise creation overhead when calculating the estimated transfer size of the output files during an
optimized build has been reduced by directly using the `brotliCompress` Node.js function instead of using
a promisified variant. Node.js Only provides a callback-based async variant for brotli compression. This
change allows for a single promise to be used.
The long-form variant of the `index` option for the `application` builder now supports
an addition sub-option named `preloadInitial`. This new option is a boolean option that controls
the generation of initial preload related link elements in the generated index HTML file
for the application. Preload related link elements include `preload`, `modulepreload`,
and `preconnect` link rels for initial JavaScript and stylesheet application files.
This update introduces the ability for users to define the locations for storing `media`, `browser`, and `server` files.
You can achieve this by utilizing the extended `outputPath` option.
```json
{
"projects": {
"my-app": {
"architect": {
"build": {
"builder": "@angular-devkit/build-angular:application",
"options": {
"outputPath": {
"base": "dist/my-app",
"browser": "",
"server": "node-server",
"media": "resources"
}
}
}
}
}
}
}
```
While not recommended, choosing to set the `browser` option empty will result in files being output directly under the specified `base` path. It's important to note that this action will generate certain files like `stats.json` and `prerendered-routes.json` that aren't intended for deployment in this directory.
**Validation rules:**
- `browser` and `server` are relative to the configuration set in the `base` option.
- When SSR is enabled, `browser` cannot be set to an empty string, and cannot be the same as `server`.
- `media` is relative to the value specified in the `browser` option.
- `media` cannot be set to an empty string.
- `browser`, `media`, or `server` cannot contain slashes.
Closes: #26632 and closes: #26057
Similar to the `dev-server` builder, the `application` builder's programmatic usage can now transform
the index HTML that is generated during a build. 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 third parameter of the `buildApplication` function can now be an extensions object with one of the fields
being `indexHtmlTransformer`. This newly introduced field allows adjusting the index HTML content.
Closes#26299
When an optimized Sass stylesheet becomes an empty string the AOT Angular host adapter
was previously treating this as a falsy value and using the original content of the
stylesheet. Empty strings are now considered valid values and will be passed to the
AOT compiler as such.
This improvement harmonizes the proxy configuration loading mechanisms between the dev-server and ssr-dev-server. Previously, these servers used different methods for loading the proxy configuration, leading to inconsistencies. Notably, the ssr-dev-server was limited to loading configurations only in JSON format. This change enables the ssr-dev-server to support various configuration formats, aligning it with the dev-server's capabilities and improving overall developer experience.
Before this update, removing the modified file entry from `typeScriptFileCache` when a file was saved but unmodified created an issue. The TypeScript compiler didn't re-emit the file using `emitNextAffectedFile` because the file hashes remained unchanged. Consequently, this led to missing files in the esbuild compilation process.
In the current update, we no longer delete entries from typeScriptFileCache. This adjustment resolves the problem by ensuring the proper handling of file recompilation and prevents files from going missing during the esbuild compilation.
Closes#26635
The load result caching capabilities of the Angular compiler plugin used within the
`application` and `browser-esbuild` builders is now used for both stylesheet and
template component resources when building in JIT mode. This limits the amount of
file system access required during a rebuild in JIT mode and also more accurately
captures the full set of watched files.
Prior to this change, watching of an `npm link` of a library in another workspace when `preserveSymlinks` was set to `true` was not being picked up as `node_modules` files were always ignored.
Closes#25753
The underlying file watching functionality now uses the `watchpack` library for all
builders. This includes the Webpack-based `browser` and the esbuild-based `application`/
`browser-esbuild`. This not only has the advantage of a single dependency for both but also
provides more consistent behavior between the two build system in regards to file watching.
Since the implementation of the file watching is fully encapsulated, there is no change to
the options or configurations of consuming applications.
The `deleteOutputPath` option will now empty specific build artifact directories instead of
removing them completely. This allows for symlinking or mounting the directories via Docker.
This is similar to the current behavior of emptying the root output path to allow similar
actions. All previous files will still be removed when the `deleteOutputPath` option is enabled.
This is useful in situations were the browser output files may be symlinked onto another
location on disk that is setup as a development server, or a Docker configuration mounts the browser
and server output to different locations on the host machine.
When using the builder harness in unit tests, expectations can now be made directly for
directories. Currently the existence, or lack thereof, can be tested using the harness.
This is similar to be existing file expectations. More capability may be added as needed
in the future.
`@import url()` to Google and Adobe fonts that are located in global and component CSS will now be inlined when using the esbuild based builders.
Input
```css
@import url(https://fonts.googleapis.com/css?family=Roboto:300,400,500);
```
Output
```css
/* latin */
@font-face {
font-family: 'Roboto';
font-style: normal;
font-weight: 500;
src: url(https://fonts.gstatic.com/s/roboto/v30/KFOlCnqEu92Fr1MmEU9fBBc4AMP6lQ.woff2) format('woff2');
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}
```
Closes#23054
TypeScript 5.3 provides a new programmatically accessible option on the compiler host object
to control the amount of JSDoc parsing that the TypeScript parser will perform. The `tsc`
command line tool now uses the `ParseForTypeErrors` value which only parses JSDoc comments
that may affect type checking and is considered a good default for tools such as the Angular
CLI. The Angular CLI will now attempt to use the `ParseForTypeErrors` value as well when available.
Projects will need to use TypeScript 5.3+ for this option to be available. No behavior changes will
occur on TypeScript 5.2 projects. This should not only provide a small improvement to build times
but also a reduction in overall memory usage.
This commit fixes an issue were when using a `baseHref` with trailing slash, vite dev-server would have been only accessible via a URL with a trailing slash. As vite would redirect to an error page similar to the below;
```
The server is configured with a public base URL of /myapp/ - did you mean to visit [/myapp/](http://localhost:4200/myapp/) instead?
```
Closes: #26618
To ensure that the `forceEsbuild` development server option chooses the correct underlying build implementation when
the project contains the `browser` builder within the build target, an explicit check and conversion of the builder
name is now performed during the initialization phase of the development server builder.
