Logging types are now based on the BuilderContext's type instead of the
`@angular-devkit/core` type. This reduces the need to directly depend
on this package while also allowing the builder logging type to diverge
if needed. The two usages of the BaseException type which is a small
wrapper around Error have also been removed.
The `i18n` project field is used to configure i18n behavior for a project.
The validation code has been reorganized to use two helper functions to
centralize the type validation and exception throwing. This reduces the complexity
of the analysis code as well as removing the need to rely on `@angular-devkit/core`.
Previously, a race condition could occur due to the spinner, resulting in the deletion of the last printed log when warnings or errors were present. With this update, we ensure that logs are printed after the spinner has stopped.
Fixes#27233
This commit removes the legacy Sass implementation previously used with Webpack.
BREAKING CHANGE: The support for the legacy Sass build pipeline, previously accessible via `NG_BUILD_LEGACY_SASS` when utilizing webpack-based builders, has been removed.
Only the injected index HTML file references and component stylesheets require
the modification of relative URLs with a public path when specified. Other
usages are already resolved relative to their containing file location with
the `application` builder.
The usage of several Webpack-centric option helper functions has now been
removed from the `application` builder. This allows for more efficient
processing of incoming options but also removes additional imports across
builder code.
`optimizeDeps.disabled` has been deprecated in favor of `optimizeDeps.noDiscovery` to `true` and `optimizeDeps.include` to `undefined`
```
(!) Experimental ssr.optimizeDeps.disabled and deps pre-bundling during build were removed in Vite 5.1.
To disable the deps optimizer, set ssr.optimizeDeps.noDiscovery to true and ssr.optimizeDeps.include as undefined or empty.
Please remove ssr.optimizeDeps.disabled from your config.
```
When purging stale build cache entries, the `readdir` call will fail if
the cache base path does not exist. This allows for a single check and
the removal of the previous separate `existSync` call. Additionally,
a repeat join call has also been removed during the stale directory check.
The Node.js `node:util` builtin contains a helper (`stripVTControlCharacters`) that
can be used to remove ANSI color characters from a string. Usage removes the need
for a custom helper within the package.
The Node.js async `pipeline` helper function reduces the amount of infrastructure code
needed to pipe HTML content through the parse5 transform stream.
The globally available TextDecoder class will automatically handle the presence of a BOM in
text files when decoding. This allows the removal of the utility function present in the
package to do the same.
To support future package building as ESM, the direct usage of require has now been
removed from the Angular compatibility check code used by various builders.
Additionally, the limited use of `@angular-devkit/core` has also been removed from
the check code as it was only used to adjust string values for error messages which
can be done directly instead.
The logic to detect media output files was previously predicated on the presence of a media subdirectory
being defined. Prior to the ability to customize output path subcomponents there was a guaranteed media
subdirectory. However, now that customization is possible, there is the potential for media files to
not have a distinct subdirectory in the output. To facilitate output media detection in this scenario
a file extension based method is now employed. This avoids a dependence on output directory structure.
The latest version of the worker pool package used by the build system (`Piscina`) now
has an option to disable performance timing information. Since the build system does
not currently use that information, disabling it avoids the extra overhead of histogram
creation and usage. This information collection could potentially be enabled conditionally
in the future if needed.
Unlike the non-ESM Node.js resolution for JS files, CSS does not have the concept
of implicit file extensions. To avoid incorrectly resolving a file as CSS,
stylesheet bundling no longer attempts to resolve implicit extensions. Preprocessors,
such as Sass, contain logic internally that handles any specific resolution cases
for their respective preprocessor and such behavior is unaffected.
The sourcemap for the Vite client code was previously not being loaded along with the
actual code. This could lead to browser 404 console messages when debugging applications.
Updates the `fileReplacement` pattern to allow `.mts` and `.cts` files.
This enables support for TypeScript files with explicit ESM support.
Closes#27124
In certain cases, the plugin option may be a string value, as shown in the example below:
```json
{
"plugins": {
"tailwindcss/nesting": "postcss-nesting"
}
}
```
In certain cases, the plugin option may be a string value, as shown in the example below:
```json
{
"plugins": {
"tailwindcss/nesting": "postcss-nesting"
}
}
```
See: https://tailwindcss.com/docs/using-with-preprocessors#nesting
The `copy-webpack-plugin@12` package has a dependency on the `globby@14` package. The recently released
`globby@14.0.1` uses the `merge-streams@2.1.0` package which requires a minimum Node.js version higher
than the officially supported 18.13 for the Angular CLI. Due to both `globby` and `merge-streams` being
transitive dependencies in end-user projects, the Angular CLI cannot directly control the package versions.
However, `copy-webpack-plugin@11` uses `globby@13` which is not affected by the Node.js version problem.
To workaround the Node.js compatibility problem, `copy-webpack-plugin` has been downgraded to version 11.0.0
which is the latest version in the 11 major for the package. The `copy-webpack-plugin` is only used with the
Webpack-based builders when in watch mode. From a review of the commit history between 11.0.0 and 12.0.2 (latest
at the time of this commit), it appears the only notable changes are several performance improvements and the
major version update of `globby`.
To avoid the Vite-based development server's prebundling system from attempting to
prebundle import statements containing absolute URLs, the set of external specifiers
will now be pre-filtered before being passed onto Vite. Currently, the check for
an absolute URL is any specifier starting with `http://`, `https://`, or '//'.
Previously, the check for determining the correct main entry point for a bundled web worker
found in application code could incorrectly use a lazy chunk created from the worker bundling
under certain situations. The check has now been made more strict to mitigate these situations.
The `application` builder now supports a new option named `define`. This option allows
global identifiers present in the code to be replaced with another value at build time.
This is similar to the behavior of Webpack's `DefinePlugin` which was previously used with
some custom Webpack configurations that used third-party builders. The option has similar
capabilities to the `esbuild` option of the same name. The documentation for that option
can be found here: https://esbuild.github.io/api/#define
The command line capabilities of the Angular CLI option are not yet implemented and will added
in a future change.
The option within the `angular.json` configuration file is of the form of an object. The keys
of the object represent the global identifier to replace and the values of the object represent
the corresponding replacement value for the identifier. An example is as follows:
```
"define": {
"SOME_CONSTANT": "5",
"ANOTHER": "'this is a string literal'"
}
```
All replacement values are defined as strings within the configuration file. If the replacement
is intended to be an actual string literal, it should be enclosed in single quote marks. This
allows the flexibility of using any valid JSON type as well as a different identifier as a replacement.
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 const SOME_CONSTANT: number;
declare const ANOTHER: string;
```
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.
An important caveat to the option is that it does not function when used with values
contained within Angular metadata such as a Component or Directive decorator. This
limitation was present with previous third-party builder usage as well.
Prior to this commit, the Vite html fallback middleware failed to handle the in-memory assets generated by Angular CLI, resulting in incorrect fallback behavior. For instance, when an `index.html` existed as an asset under a specific path, the generated `index.html` would be served instead.
This fix addresses the issue, ensuring that the appropriate `.html` is served when using the Vite dev-server.
Closes#27044
Previously, the Vite-based development server that is automatically used with the `application`
and `browser-esbuild` builders would always use prebundling if the Angular CLI caching was enabled.
The development server now has a specific `prebundle` option to allow more control over prebundling
while still allowing other forms of caching within the Angular CLI. The `prebundle` option
can be a boolean value of `true` or `false` that will enable or disable prebundling, respectively.
Additionally, the option also has an object long-form. This long-form enables prebundling and
currently contains one property named `exclude`. The `exclude` property supports cases where a
package should not be prebundled and rather should be bundled directly into the application code.
These cases are not common but can happen based on project specific requirements.
If the `prebundle` option is enabled when using the `browser` builder or any other Webpack-based
builder, it will be ignored as the Webpack-based development server does not contain such
functionality.
