Application builds will now support the direct import of WASM files.
The behavior follows the WebAssembly/ES module integration proposal. The usage
of this feature requires the ability to use native async/await and top-level
await. Due to this requirement, applications must be zoneless to use this new
feature. Applications that use Zone.js are currently incompatible and an error
will be generated if the feature is used in a Zone.js application. Manual
setup of a WASM file is, however, possible in a Zone.js application if WASM
usage is required. Further details for manual setup can be found here:
https://developer.mozilla.org/en-US/docs/WebAssembly/Loading_and_running
The following is a brief example of using a WASM file in the new feature
with the integration proposal behavior:
```
import { multiply } from './example.wasm';
console.log(multiply(4, 5));
```
NOTE: TypeScript will not automatically understand the types for WASM files.
Type definition files will need to be created for each WASM file to allow
for an error-free build. These type definition files are specific to each
individual WASM file and will either need to be manually created or provided
by library authors.
The feature relies on an active proposal which may change as it progresses
through the standardization process. This may result in behavioral differences
between versions.
Proposal Details: https://github.com/WebAssembly/esm-integration/tree/main/proposals/esm-integration
For more information regarding zoneless applications, you can visit https://angular.dev/guide/experimental/zoneless
The babel-based JavaScript transformer currently requires a syntax plugin
to support import attributes. Import attributes are otherwise supported in
application code. However, in production builds the JavaScript transformations
such as the build optimizer passes would fail on code that contain any import
attributes. The inclusion of the babel syntax plugin removes this problem.
Once babel provides built-in support for this syntax feature, the plugin
can be removed.
With the potential future introduction of features such as WASM/ES module integration
and the experimental chunk optimizer, the need to restrict top-level await
usage is no longer needed and a blocker for new features. As such, top-level
await will now be available if an application has been configured to be
zoneless.
Zoneless Angular is currently experimental and more details can be found here:
https://angular.dev/guide/experimental/zoneless
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.
Prior to this commit, accessing a static asset directory without a trailing slash resulted in a 404 error. With this change, we now redirect to the path with a trailing slash, aligning with the behavior of express static.
Closes#27949
An experimental chunk optimizer is now available for initial usage.
To enable the optimization, script optimization must be enabled as well as
an environment variable `NG_BUILD_OPTIMIZE_CHUNKS=1`. This build step uses
`rollup` internally to process the build files directly in memory. The main
bundling performs all resolution, bundling, and tree-shaking of the application.
The chunk optimizer step then only needs to access the in-memory built files and does not
need to perform any disk access or module resolution. This allows the step to be
performed fairly quickly but it does add time to the overall production build.
The `NG_BUILD_DEBUG_PERF=1` environment variable can be used to view how long the step
takes within a build via the `OPTIMIZE_CHUNKS` entry. In the future, this optimization
step may be automatically enabled based on initial file entry count and size.
There are several current known issues:
1) Bundle budgets for named lazy chunks may not work as expected.
2) The console output may not show names (files will be present) for lazy chunk files.
3) The stats file (`--stats-json` option) will not exactly reflect the final written application files. This is similar to the current behavior of the `browser` builder with Webpack's stat file.
The bundle budget calculators and the console build stats output are now
calculated directly from the build output file information instead of the
esbuild metafile where possible. This provides a more generic method of
accessing the information and can more accurately account for post-processing
steps that may alter the output files. The metafile is still used for
component style budgets and lazy chunk name information.
The `BuildOutputFile` type's helper functions have been adjusted to cache
commonly accessed property values to avoid potentially expensive repeat
processing. This includes encoding/decoding UTF-8 content and calculating
hash values for the output file content. A size property has also been
added to allow consumers to more directly determine the byte size of the
output file. The size property is currently unused but will be leveraged
in forthcoming updates to bundle budgets and console info logging.
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.
Due to bazel rules_nodejs caching, several additional `JSON.parse` usages were not
caught in the first set of fixes. These have now been addressed. Also,
the `must-use-promises` rule has been patched to match the behavior of the
`@typescript-eslint/no-floating-promises` for consistency.
The bazel option `suppressTsconfigOverrideWarnings` was also removed from the
`tsconfig` as it is a no-op and was previously used for now removed feature.
Test files are currently excluded from the `JSON.parse` rule to avoid large
changes to test code.
Replacing the paths to ESM in Vite can cause prebundling to fail in some cases, resulting in errors similar to the following:
```
12:55:12 PM [vite] Error when evaluating SSR module /chunk-CHB4JJIP.mjs:
|- TypeError: Cannot read properties of undefined (reading 'Subject')
at eval (//src/app/shared/snackbar/snackbar.service.ts:2:25)
at async instantiateModule (file:////node_modules/vite/dist/node/chunks/dep-BcXSligG.js:53408:5)
12:55:12 PM [vite] Error when evaluating SSR module /chunk-GQZ5BKXC.mjs:
|- TypeError: Cannot read properties of undefined (reading 'Subject')
at eval (//src/app/shared/snackbar/snackbar.service.ts:2:25)
at async instantiateModule (file:////node_modules/vite/dist/node/chunks/dep-BcXSligG.js:53408:5)
```
Closes: #27907
The TypeScript `isolatedModules` option is now enabled for all TypeScript
code within the repository. As a result, all packages will now be built
with the option enabled. This does not affect projects created with the CLI
and is only related to the building of the actual Angular CLI code.
The `isolatedModules` option ensures that code can be emitted without the
TypeScript typechecker and allows tools other than TypeScript to potentially
be used. Code was updated to correct all errors after the option was enabled.
Additionally, some early code fixes were done to add function and accessor
return types to prepare for future `isolatedDeclarations` usage. More changes
would be needed to consider turning on `isolatedDeclarations`, however.
If the persistent cache store for the JavaScript transformations fails
to initialize, a warning will now be shown to better explain the outcome
and to allow the build to continue. The build will still complete without
the cache but may be slower to finish.
The bundler context class now has a static helper method to support merging
bundler results outside of a specific bundle action. This will be used in the
future to support more complex bundling hierarchies.
The Angular compiler code that is not specific to esbuild has been moved
into a separate `tools` subdirectory. This allows for potential reuse internal
reuse outside of the Angular esbuild plugin.
Add `createCompilerPlugin` function to the private export of the package.
Note that these are not considered part of the public API and
are intended for use only with the `@angular-devkit/build-angular` package.
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.
Prior to this change, script tags with the `src` attribute were not being assigned a CSP nonce during the build process. This is useful
strict-dynamic is a Content Security Policy (CSP) directive that simplifies the management of dynamically loaded scripts while maintaining a high level of security. It allows scripts that are initially trusted (through a nonce or hash) to load other scripts without additional restrictions.
Closes#27874
Previously, ESM file resolution without extensions failed when using Vite, causing issues in module loading. This commit addresses the problem by automatically resolving `.mjs` files, aligning the behavior with the application builder and ensuring consistent module resolution across different build tools.
**NB**: This is a workaround as valid ESM imports should always have an extension.
Closes#27841
This commit addresses an issue where sourcemaps in web workers and global stylesheets were referenced despite the hidden setting being enabled.
Closes: #27833
Previously, PostCSS was initialized three times (once for each preprocessor), resulting in plugins being applied multiple times to each instance. This issue occured due to a race condition triggered by multiple esbuild plugins.
Fixes#27804
If the module preload limit is not met by shallow (depth 1) initial
scripts, deeper initial scripts can now be added. This allows for
deeper import graphs to take advantage of the browser's module preloading.
Additionally, the limit has been increased to ten now that the module
preloads are added at the end of the body along with the actual script elements.
The `modulepreload` link elements for initial scripts are now generated next to the
actual script elements that require the referenced preloaded scripts. This better
represents the fetch priorities to the browser and also allows easier visual discovery
of the relevant script related elements inside the index HTML.
This commit introduces a warning for when the application builders automatically add the @angular/localize/init polyfill. The current approach has a drawback: the localize polyfill will always be included if it is found in a monorepo, even if an application does not use i18n.
To address this, we will issue a warning to inform users about this behavior and encourage them to explicitly add the polyfill to their polyfills configuration.
Additionally, this commit fixes an issue where the polyfill was not removed when using the build-time Angular i18n.
The `inquirer` package has been rewritten with a new set of packages.
The rewrite had a focus on reduced package size and improved performance.
The main prompt package is now `@inquirer/prompts`. However, for `@angular/build`
only the confirm prompt is needed so the `@inquirer/confirm` package can be
used directly to further reduce dependencies.
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)
When using the application builder and the TypeScript `isolatedModules`
option is enabled and script sourcemaps are disabled, TypeScript code
will be transpiled via the bundler instead of the current behavior of
using TypeScript. The use of the `isolatedModules` option ensures that
TypeScript code can be safely transpiled without the need for the type-checker.
This mode of operation has several advantages. The bundler (esbuild in this case)
will know have knowledge of the TypeScript code constructs, such as enums, and can
optimize the output code based on that knowledge including inlining both
const and regular enums where possible. Additionally, this allows for
the removal of the babel-based optimization passes for all TypeScript
code. These passes are still present for all JavaScript code such as
from third-party libraries/packages. These advantages lead to an
improvement in build time, especially in production configurations.
To ensure optimal output code size in this setup, the `useDefineForClassFields`
TypeScript option should either be removed or set to `true` which
enables ECMAScript standard compliant behavior.
Initial testing reduced a warm production build of a newly generated
project from ~2.3 seconds to ~2.0 seconds.
This commit introduces an `--inspect` option to the dev-server, enabling debugging of server-side code when using SSR or SSG. This option is equivalent to `node --inspect=[[host:]port]`.
Usage examples:
```
$ ng serve --inspect
$ ng serve --inspect 9999
$ ng serve --inspect localhost:9999
```
Closes: #27773
When `dart-sass` returns an error, the provided location span may not be
the exact location of the error but can instead be the location of the
`@error` call within a Sass function. The generated stack trace string
does contain all files related to the error including the usage site in
the case of the function `@error` case. To ensure all related files for
the error are watched and allow for a rebuild that may correct the error,
the stack trace is parsed and found files are added to the watch list.
Unfortunately, `dart-sass` does not provide the list directly. If that
changes in the future, the stack trace parsing could be removed.
The backing store for the persistent caching of the JavaScript transformers
is not currently supported on web containers. To allow other potential forms
of caching, the JavaScript transformer caching is now selectively disabled
when executed on a web container. This allows for development server prebundling
to be used on web containers if needed.
