All specified locales in the i18n configuration for an application use the `application` or `browser-esbuild`
builders will now be normalized using the `Intl` API. This ensures that the provided locale tags are both
well-formed and correctly cased. This also more easily allowed an optimization for the default locale which
is already embedded into the framework and will now no longer be injected by the build process if active.
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` builder with progress enabled (the default), the spinner text will
now automatically contain a trailing newline. This ensures that any diagnostic messages are not
awkwardly printed on the same line as the spinner.
This commit updates the file watcher to only use rename and change events from raw events and will otherwise rely on all events to capture other file changes.
The rename and change events are watch are triggered when using IDEs that use atomic writes. This should improve cross-platform and cross IDE compatibility.
By default, on Mac OSX chokidar will use the native darwin FSEvents API unless polling is enabled. In which case instead of listening on `raw` events we need to listen to `all` events.
This commit, fixes a file watching issue where file changes events are not triggered when using IDEs like Visual Studio (not VS Code).
The main changes to solve the issue are;
## Replace `watcher.on('all')` with `watcher.on('raw')`
Using `watcher.on('all')` does not capture some of events fired when using Visual studio and this does not happen all the time, but only after a file has been changed 3 or more times.
```
watcher.on('raw')
Change 1
rename | 'C:/../src/app/app.component.css'
rename | 'C:/../src/app/app.component.css'
change | 'C:/../src/app/app.component.css'
Change 2
rename | 'C:/../src/app/app.component.css'
rename | 'C:/../src/app/app.component.css'
change | 'C:/../src/app/app.component.css'
Change 3
rename | 'C:/../src/app/app.component.css'
rename | 'C:/../src/app/app.component.css'
change | 'C:/../src/app/app.component.css'
watcher.on('all')
Change 1
change | 'C:\\..\\src\\app\\app.component.css'
Change 2
unlink | 'C:\\..\\src\\app\\app.component.css'
Change 3
... (Nothing)
```
## Handle `rename` events
Some IDEs will fire a rename event instead of unlink/changed when a file is modified}
Closes#26437
(cherry picked from commit 1725b91e357f613f7fb7547d13d6499973ee3849)
This reverts commit bbbe13d6782ba9d1b80473a98ea95bc301c48597.
Switching to `raw` event changes the event names such that some events are getting dropped and breaking watch mode rebuilds on Mac.
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.
In some cases the `$localize.locale` was being set prior to `$localize` being set through `@angular/localize`. This caused `$localize.locale` to be reset to `en-US`.
This change moves the order in which `$localize.locale` is set.
Partially addresses: #26350
This commit, fixes a file watching issue where file changes events are not triggered when using IDEs like Visual Studio (not VS Code).
The main changes to solve the issue are;
## Replace `watcher.on('all')` with `watcher.on('raw')`
Using `watcher.on('all')` does not capture some of events fired when using Visual studio and this does not happen all the time, but only after a file has been changed 3 or more times.
```
watcher.on('raw')
Change 1
rename | 'C:/../src/app/app.component.css'
rename | 'C:/../src/app/app.component.css'
change | 'C:/../src/app/app.component.css'
Change 2
rename | 'C:/../src/app/app.component.css'
rename | 'C:/../src/app/app.component.css'
change | 'C:/../src/app/app.component.css'
Change 3
rename | 'C:/../src/app/app.component.css'
rename | 'C:/../src/app/app.component.css'
change | 'C:/../src/app/app.component.css'
watcher.on('all')
Change 1
change | 'C:\\..\\src\\app\\app.component.css'
Change 2
unlink | 'C:\\..\\src\\app\\app.component.css'
Change 3
... (Nothing)
```
## Handle `rename` events
Some IDEs will fire a rename event instead of unlink/changed when a file is modified}
Closes#26437
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.
When the `preserveSymlinks` option is false (the default), the tsconfig path was
passed through realpath to ensure that the TypeScript source files were resolved
correctly. However, the promise version of the Node.js API was previously used.
This version used `realpath.native` internally but the native version has numerous
behavior problems on Windows systems. This includes potential case conversion
which can result in differing cases for files within the build system and in turn
failed path comparison checks. The synchronous version is now used which has a
JavaScript implementation that does not suffer from these problems.
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.
This changes enables wrapping classes in side-effect free modules that make use of custom decorators when using the esbuild based builders so that when such classes are unused they can be treeshaken.
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.
When using the `application` or `browser-esbuild` builder in watch mode on Windows, the project root
will now be watched by default. This provides a workaround for users of Visual Studio which uses a
file save mechanism that causes the watch mode to not correctly trigger. By watching the entire
project root, this problem is avoided. However, this may result in additional rebuilds due to changes
of unrelated files in the project root.
This behavior can be disabled using the environment variable `NG_BUILD_WATCH_ROOT=0`. On non-Windows
platforms, disabled is the default.
Addresses #26437
Prior to this change a postcss instance was created for every component style. This can cause a performance overhead when using tailwindcss, since each tailwind instance would do multiple IO calls to get the list of files specified in the `content` field.
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.
The path comparisons for the TypeScript and AOT file reference tracking now use the native path normalization
functions. This avoids issues where the TypeScript paths which use POSIX separators may not correct match
system paths. The file reference tracking is used to trigger updates to both web workers as well as component
stylesheets that have preprocessor (Sass/Less/etc.) dependencies.
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
The TypeScript compiler converts all paths to use POSIX path separators. When on Windows,
this can cause problems when comparing paths from other parts of the build system including
the file watching provided by `chokidar`. The referenced files returned from the TypeScript
compiler are now normalized to the native path format to mitigate this problem. This also
avoids an issue where the same files but with differing path separators were included in
the watch files list on Windows due to the bundler using native paths and TypeScript using
converted paths.
The path comparisons for the TypeScript emit file lookups now use the native path normalization
functions. This removes the special handling previously used and better ensures that cache checks
are valid. The separate babel cache Map has also been combined with the already present memory
load cache within the Angular plugin. This removes the need for extra handling of another Map and
allows it to use the common logic of the load cache. To support this usage, the load cache will
also now automatically include the request path in the file dependencies if the request is from
the `file` namespace. This removes the need to manually specify the request path file for each
load result return value.
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.
