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 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.
`@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
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.
Vite appears to consider a port value of `0` as a falsy value and use the default Vite port of
`5173` when zero is used as a value for the development server port option. To workaround this
issue, the port checker code now explicitly handles the zero value case and determines a random
port as would be done automatically by the Webpack-based development server.
This commit enables users to disable runnings tests against a browsers. This can be done by using the `--no-browsers` command line flag or setting `browsers` to `false` in the `angular.json`
Closes#26537
`browser-sync` is now an optional dependency of `@angular-devkit/build-angular`. This package is only needed when using the legacy `@angular-devkit/build-angular:ssr-dev-server` builder.
Closes#26349
In some cases, the index.html file emitted contained the wrong contents. This because in OutputFiles there were present multiple files with the same name.
Closes#26593
The `@use` Sass directive allows Sass variables to be accessed via a namespace. This was
previously not checked when performing URL path rebasing on imported Sass stylesheets.
These type of Sass variable references are now also ignored when attempting to rebase URL
paths during loading. The final rebased URL now also does not add a leading relative prefix
indicator (`./`) unless not already present.
The Vite-based development server uses an allow list to permit access to configured assets. This list
is checked internally to Vite by using its normalized path form. To ensure that assets provided by the
build are checked correctly on all platforms, the asset list is now normalized with Vite's path
normalization prior to being used.
When using the `application` or `browser-esbuild` builders, the internal advanced optimizations
can only be applied when in AOT mode. However, they were previously only checking the AOT mode
and not whether the project was configured to use script optimizations. The advanced optimizations
are now conditional on both AOT mode and the `optimization.scripts` option. This can greatly
improve the performance of builds in development since the Babel related processing can be skipped
for all TypeScript application code.
An AbortController is now automatically linked to the `application` builder's teardown context
if one has not been provided. This supports reduced overhead in the unit tests by eliminating
the need to manually create and use an AbortController/AbortSignal in each test that uses watch
mode. Relevant tests that were previously doing this have also been updated.
When using the `application` or `browser-esbuild` builders with the `dev-server`, interactive key
shortcuts are now available to use while the server is active. Once the build has successfully completed
and the development server has initialized, typing a single letter key followed by enter will execute
the associated action. These actions include forcing a browser full reload, clearing the console, or
quitting. More actions may be added in the future.
The following actions are currently available:
```
press r + enter to force reload browser
press u + enter to show server url
press o + enter to open in browser
press c + enter to clear console
press q + enter to quit
```
The `h` action is also available which will display the above list at runtime.
Prior to this change special CSS comments `/*! comment */` were being removed during minification when using the application builder. This caused tools that ran post build that rely on such comments such as purgeCSS and critters not to function properly.
We now provide a `removeSpecialComments` option to enable retention of these comments in global CSS files.
Usage example:
```json
{
"projects": {
"my-app": {
"architect": {
"build": {
"builder": "@angular-devkit/build-angular:application",
"configurations": {
"production": {
"optimization": {
"styles": {
"removeSpecialComments": false
}
}
}
}
}
}
}
}
}
```
Closes: #26432
When using the `application` or `browser-esbuild` builders, localization errors were
previously not being propagated to the final build result. In the event that the
`i18nMissingTranslation` option was changed to error from the default of warning, the
final build result would previously indicate a success if there were any missing translations
present within the build. This has now been corrected and the build will now fully fail
including a non-zero exit code in this case.
When not preserving symlinks (the default), the workspace root path should be converted
to the real path on the filesystem to ensure that resolution of all other path-based build
options reflects the actual location of the files. This ensures that typescript and esbuild
resolve files in a consistent manner and avoids hard to diagnose errors involving missing
files at build time.
To minimize ambiguity, the update related log messages for the development server now consistently
indicate that the page reload, HMR update, or otherwise has actually been sent to any connected clients.
The Vite-based development server restricts filesystem access by default. However, assets
configured by the build option `assets` are intended to be accessible by the application at
runtime. To ensure that these files are accessible, the allow list will now explicitly include
all configured assets found during the build.
The generated HTML files for the application were previously not included in the hash calculations for
the service worker. This has now been corrected and the index file for an application will not be included
when service worker support is enabled via the `serviceWorker` option.
With the Vite-based development server, the build pipeline itself watches for files
and rebuilds the relevant parts of the application as needed. The Vite file watching
is unneeded and was previously setup to ignore all files. This worked but was not
ideal as chokidar was still initialized inside Vite. However, Vite now supports fully
disabling the file watching by passing `null` for the Vite watch option value.
The application builder logic will now be used when the Vite-based development server is used with a
custom builder. This aligns with the programmatic export of application builder. This allows consistent
behavior for custom builders that use both the application builder and dev server builder APIs.
A unit-test for the application builder has been added to that tests the rebuilds are triggered when
a template error has been introduced in a rebuild. The test also confirms that rebuilds continue to
function after the error has been corrected.
To avoid potential confusion when updating to v17, the usage warning as been removed
from the `browser-esbuild` builder. The `browser-esbuild` builder is considered stable
and fully supported. This is in addition to the other stable builders: `browser` and
`application`. The `browser-esbuild` builder provides similar behavior to the `browser`
builder but with the performance improvements of the `application` builder. However,
`browser-esbuild` does not have integrated SSR support and will not receive new/future
`application` builder options and features.
For more details on these builders, please see: https://angular.io/guide/esbuild
When using the `application` builder, a new `loader` option is now available for use.
The option allows a project to define the type of loader to use with a specified file extension.
A file with the defined extension can then used within the application code via an import statement
or dynamic import expression, for instance.
The available loaders that can be used are:
* `text` - inlines the content as a string
* `binary` - inlines the content as a Uint8Array
* `file` - emits the file and provides the runtime location of the file
* `empty` - considers the content to be empty and will not include it in bundles
The loader option is an object-based option with the keys used to define the file extension and the values used
to define the loader type.
An example to inline the content of SVG files into the bundled application would be as follows:
```
loader: {
".svg": "text"
}
```
An SVG file can then be imported:
```
import contents from './some-file.svg';
```
Additionally, TypeScript needs to be aware of the module type for the import to prevent type-checking
errors during the build. This can be accomplished with an additional type definition file within the
application source code (`src/types.d.ts`, for example) with the following or similar content:
```
declare module "*.svg" {
const content: string;
export default content;
}
```
The default project configuration is already setup to use any type definition files present in the project
source directories. If the TypeScript configuration for the project has been altered, the tsconfig may
need to be adjusted to reference this newly added type definition file.
