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.
To support future use cases, the internal `externalPackages` application builder option now also
accepts an object form with an `exclude` array field in addition to the existing boolean value.
The `exclude` capability allows for specifying individual packages that should always be bundled
when using the external packages functionality. Currently the external packages functionality is
only used by the Vite-based development server.
Since this change 4b3a965429
A warning is displayed when using `./` as a base href
```
(!) invalid "base" option: ".". The value can only be an absolute URL, "./", or an empty string.
```
This change implements the capability to display JSON build logs in the terminal instead of a format readable by humans. This is particularly useful for hosting providers, as it allows them to effortlessly access the necessary information without having to parse the JSON configuration.
To enable this output, set the `NG_BUILD_LOGS_JSON=1` environment variable. Additionally, warnings, errors, and logs are automatically colorized when the standard output is a WritableStream. You can disable the colors by using the `FORCE_COLOR=0` environment variable.
```
FORCE_COLOR=0 NG_BUILD_LOGS_JSON=1 ng b
{
"errors": [],
"warnings": [],
"outputPaths": {
"root": "file:///usr/local/test/home//test-project/dist/test-project",
"browser": "file:///usr/local/test/home//test-project/dist/test-project/browser",
"server": "file:///usr/local/test/home//test-project/dist/test-project/server"
},
"prerenderedRoutes": [
"/"
]
}
```
```
NG_BUILD_LOGS_JSON=1 ng b
{
"errors": [],
"warnings": [],
"outputPaths": {
"root": "file:///usr/local/test/home//test-project/dist/test-project",
"browser": "file:///usr/local/test/home//test-project/dist/test-project/browser",
"server": "file:///usr/local/test/home//test-project/dist/test-project/server"
},
"prerenderedRoutes": [
"/"
]
}
```
When using the `application` builder, the usage of a custom postcss configuration is now supported.
The builder will automatically detect and use specific postcss configuration files if present in
either the project root directory or the workspace root. Files present in the project root will have
priority over a workspace root file. If using a custom postcss configuration file, the automatic
tailwind integration will be disabled. To use both a custom postcss configuration and tailwind, the
tailwind setup must be included in the custom postcss configuration file.
The configuration files must be JSON and named one of the following:
* `postcss.config.json`
* `.postcssrc.json`
A configuration file can use either an array form or an object form to setup plugins.
An example of the array form:
```
{
"plugins": [
"tailwindcss",
["rtlcss", { "useCalc": true }]
]
}
```
The same in an object form:
```
{
"plugins": {
"tailwindcss": {},
"rtlcss": { "useCalc": true }
}
}
```
NOTE: Using a custom postcss configuration may result in reduced build and rebuild
performance. Postcss will be used to process all global and component stylesheets
when a custom configuration is present. Without a custom postcss configuration,
postcss is only used for a stylesheet when tailwind is enabled and the stylesheet
requires tailwind processing.
Prior to this change in the stats table we listed all the lazy chunk, in some cases this could be hundreds of files.
With this change, we limit the number of files listed. To display all entire list of files users would need to use the `--verbose` flag.
The `elide-angular-metadata` build optimization pass have been cleaned up
and restructured to remove the need for a direct runtime dependency on `@babel/core`.
The `pure-toplevel-functions` build optimization pass have been cleaned up
and restructured to remove the need for a direct runtime dependency on `@babel/core`.
Prior to this change using an absolute path as a `output-path` resulted in the path to be combined with the workspace root instead of resolved which caused the output to be emitted in the incorrect directory or error in Windows.
Closes#26935
The `load` event for each stylesheet may not always be triggered by Google Chrome's handling. Refer to: https://crbug.com/1521256
This results in the media attribute persistently being set to print, leading to distorted styles in the UI. To address this issue, we substitute the onload logic by replacing `link.addEventListener('load', ...` with `document.documentElement.addEventListener('load', ...` and filtering for link tags.
Closes#26932
Vite v5 updated the client code's error dialog text. This requires that the
text replacement code also be updated to remove unactionable information from
the error dialog.
Previously, the `application` builder would consider all imports originating from a package
to be considered external when caching was enabled. This allows Vite's prebundling to function
and optimize the build/rebuild experience for the development server. However, when using the
newly introduced `loader` option, this also inadvertently caused files that should be affected
by the option that originate from a package to also be considered external. This behavior would
then prevent the loader customization from being performed. To rectify this situation, all files
that would be affected by a loader customization will not be marked as external for the purposes
of prebundling unless explicitly configured by the `externalDependencies` option.
This commit fixes a regression which causes a pre-transform error when using vite with ssr. The `request.url` is now passed to the index transformer instead of `request.originalUrl`. This is because the `request.url` will have a value of the `index.html`.
Closes#26897
