I often struggle with spacing around block comments, so I've decided to add the `lines-around-comment` lint rule to help manage this.
For more details, see the https://eslint.style/rules/js/lines-around-comment
This commit reduces the maximum number of workers to the available CPUs minus 1. This adjustment ensures that some resources are left for the main thread, preventing it from being starved of CPU cycles.
Several smaller code changes to improve type information and remove now
unneeded code structures based on improvements to both Node.js, TypeScript,
and underlying dependencies.
The Node.js `os.availableParallelism` API now provides more accurate values
when used within containers such as many CI environments. This provides a
better default when using resource limited CI setups. The value is still
set to a maximum default of four. However, the `NG_BUILD_MAX_WORKERS`
environment variable can be used to set the value to an explicit value
if required.
Updates for all angular.io links to the new angular.dev domain. Additionally, adjustment to new resources where the equivalent does not exist on the new site (e.g. Tour of Heroes tutorial)
With the `application` builder already within the new `@angular/build` package,
the Vite-based `dev-server` builder is now also contained within this package.
Only the Vite-based aspects of the `dev-server` have been moved and only the
support for the `application` builder. The compatibility builder `browser-esbuild`
is not supported with `@angular/build:dev-server`. The existing `dev-server` builder
found within `@angular-devkit/build-angular` should continue to be used for both the
Webpack-based `browser` builder and the esbuild-based compatibility `browser-esbuild`
builder. To maintain backwards compatibility, the existing `@angular-devkit/build-angular:dev-server`
builder continues to support builders it has previously.
No change to existing applications is required.
The `@angular/build` package has been introduced to house the esbuild/Vite-based
build system that was newly introduced as stable in v17. The existing
`@angular-devkit/build-angular` package will continue to contain the Webpack-based
build system and to ensure backwards compatibility it will also provide aliases
for the esbuild/Vite-based build system. The changes here are the first stage
of the builder transition and moves the `application` builder into the new package.
The application builder can now be accessed when this package is installed directly
via `@angular/build:application`.
No changes are required for existing projects.
Webpack-specific types and imports have been reduced within the logic and test code for the bundle
budget calculator. This reduces the amount of unused code that needs to be loaded when not using
a Webpack-based bundler. The Webpack component style budget plugin was also updated to use only
the `checkBudgets` function instead of the previous two function setup which limits the needed
amount of runtime exports for the plugin.
Webpack-specific types and imports have been reduced within the logic for the build stats table generation.
This reduces the amount of unused code that needs to be loaded when not using a Webpack-based bundler.
The i18n option creation for a project, which is a combination of the `i18n` project field and the `localize`
build option, is now in a separate file from the Webpack specific i18n configuration setup.
This allows the i18n option creation to be used without loading anything Webpack specific.
Instead of previously attempting to reuse the Webpack-based copy assets helper function,
the application builder will now only resolve all potential configured assets. This
avoids depending on non-obvious parameter behavior to prevent the actual copying of
the asset files.
Both the postcss and tailwind configuration file searching during the `application` builder setup look
in the project and workspace root for one of the related configuration files. To avoid unneeded
repeat file access, both searches now reuse directory contents information.
Since the calculated cache path already contains the `@angular-devkit/build-angular` package version,
the version is not needed within the cache key for each font URL. This removes the need to import the
loaded version from the `package.json` in the font inline logic.
The build process will automatically perform package version placeholder replacement within
source files. This allows for the package version to be injected into the build cache path
creation process as a constant. As the version is now a constant, there is no need to
attempt runtime loading of the package metadata to retrieve the package version.
The `assets` directory is confusing for the users and commonly users place "assets" which are not meant to be copied but instead processed by the build system. This causes some files both bundled and copied.
With this change we rename the `assets` directory to `public` and also move the `favicon.ico` inside this newly created directory.
This commit addresses an issue where the service worker incorrectly referenced a non-existent `index.html` when utilizing the output index option. Additionally, it ensures proper resolution of the service worker configuration when the option value is set to `true`.
Currently, errors occurring in ESM loader hooks while using `--import` are not correctly displayed, as they cannot be transferred from the worker to the main thread. Although the error is an instance of Error, it contains non-transferable properties and cannot be transmitted from a worker when --import is used. Consequently, when read outside of the worker, the error object displays as `[Object object]`. To address this issue, we reconstruct the error message.
See: https://github.com/angular/angular-cli/issues/27251
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`.
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.
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 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.
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
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.
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
To support generate diagnostics in varying ways, the internal compilation classes
now support a `modes` argument when diagnosing files during a build using the `application` builder.
This is not exposed as an option at this time but can be experimented with a build using the
`NG_BUILD_TYPE_CHECK` environment variable. This environment variable is not considered part of the
public API and may be removed or altered in the future. Its current purpose is to allow profiling
of the type checking diagnostics functionality of the build system.
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.
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
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.
