The `entries` option should be used instead of the `includes` option to disable the
file entry based discovery for Vite's prebundling. This discovery is unneeded due
to the built application files existing only in memory.
This is in an effort to reduce errors like `"Unknown version 114 of edge (While processing: "base$0$0")"` which are caused by mismatching versions.
Closes#25377
When using the Webpack-based browser application builder with the development server, the
proxy configuration can be in an array form when using the `proxyConfig` option. This is unfortunately
not natively supported by the Vite development server used when building with the esbuild-based
browser application builder. However, the array form can be transformed into the object form.
This transformation allows for the array form of the proxy configuration to be used by both
development server implementations.
When using the esbuild-based browser application builder, the pre-existing initial file
analysis is now used to generate preload hints for any transitive initial files required
by the application. These hints are generated for both the initial JavaScript chunks and
any initial global stylesheets that may be present. These hints provide additional
information to the browser so that it can start and better prioritize fetching of files
needed to start the application.
When using the esbuild-based browser application builder, the set of initially loaded files
for the application is now calculated by analyzing potential transitively loading JavaScript
and/or CSS files. This ensures that the full set of bundled files is available for bundle
size calculations as well as further analysis in areas such as link-based hint generation in
the application's index HTML.
This also fixes a bug where non-injected `scripts` where incorrectly shown as initial files.
When running the builder in watch mode, and fetching the git repo that the project is contained in, any changes in the .git folder trigger a rebuild. This is especially annoying when the IDE that you use periodically fetches the repository, and the FETCH_HEAD file triggers the rebuild every time. With this change the folders starting with a dot will be ignored in the watcher to avoid similar issues
When running the builder in watch mode, and fetching the git repo that the project is contained in, any changes in the .git folder trigger a rebuild. This is especially annoying when the IDE that you use periodically fetches the repository, and the FETCH_HEAD file triggers the rebuild every time. With this change the .git folder will be ignored in the watcher
The index HTML generation functionality for both the Webpack-based and esbuild-based
browser application builder now supports adding link hint elements to the generated output.
This includes `prefetch`, `preload`, `modulepreload`, `preconnect`, and `dns-prefetch` hint
modes. This functionality is not yet used by builds and will be integrated within future
changes.
When using the development server with the esbuild-based browser application builder, the underlying
Vite server will now prebundle packages present in an application. During the prebundling process,
the Angular linker will also be invoked to ensure that APF packages are processed for AOT usage.
The Vite prebundling also provides automatic persistent caching of processed packages. This allows
reuse of processed packages across `ng serve` invocations. To support the use of prebundling at the
development server level, all packages are considered external from the build level. The first time
a package is used within an application there may be a short delay upon accessing the page as the
package is processed. Due to the persistent nature of the prebundling, the `ng cache` command is used
to control the use of the feature. Please note, however, disabling the cache will also disable TypeScript
incremental compilation if not otherwise specifically disabled.
The file searching within the build system (both Webpack and esbuild) now use the
`fast-glob` package for globbing which provides a small performance improvement.
Since the assets option in particular is within the critical path of the buil pipeline,
the performance benefit from the switch will be most prevalent in asset heavy projects.
As an example, the Angular Material documentation site saw the asset discovery time
reduced by over half with the switch. `fast-glob` is also the package used by Vite
which provides additional benefit by ensuring that the Angular CLI behavior matches
that of the newly integrated Vite development server.
The Angular compiler generates two types of metadata calls when it generates AOT code.
This metadata is not used in fully AOT compiled applications and can contain direct references
to components, services, etc. that may affect the output chunk layout of the application.
While this currently has not lead to any problems, it could in the future and the Webpack
bundler already performs a transform that preemptively removes these calls. To remain
consistent, the esbuild-based build system will now also perform this transform.
This also updates the autoprefixer behavior tests to check the actual runtime style text
instead of the style text within the metadata calls.
When using the esbuild-based browser application builder, Sass and Less stylesheets will now be post-processed
with autoprefixer and/or Tailwind CSS when applicable. CSS stylesheets were already processed by these tools.
Autoprefixer is queried based on the configured browserslist to determine if any processing is required and
is not added to the build pipeline if no transformations are required. Likewise for Tailwind, if no Tailwind
configuration file is present, Tailwind CSS will also not be added to the build pipeline. If both autoprefixer
and Tailwind are not required, `postcss` (the tool used to post-process the stylesheets) itself is not added
to the build pipeline. This removes the potential for unneeded build time overhead for projects that do not
require these post-processing steps.
The default browserslist currently does require the use of autoprefixer based on autoprefixer's prefix analysis.
When using the esbuild-based browser application builder in watch mode, all files referenced
by the TypeScript program are now watched in additional to files within the project root.
This allows for more extensive monorepo setups to take advantage of watch mode as TypeScript
files may exist in other library projects within the repository.
Webpack enabled top level await by default in version 5.83.0. (See: https://github.com/webpack/webpack/releases/tag/v5.83.0)
This commit restores the previous behaviour, as top level await is not supported due to Zone.js issues.
The stylesheet related plugins for the esbuild-based browser application builder will now cache intermediate
load results when in watch mode. This reduces the potential amount of processing needed during a rebuild for
both `ng build --watch` and `ng serve`.
Within the esbuild-based browser application builder, a helper function has been introduced
to streamline the use of the load result cache within the internal plugins. This removes
repeat code that would otherwise be needed. The ability to use a load result cache with the
global script processing has also been added but has not yet been enabled.
When using the esbuild-based browser application builder with the development server, configured
application assets are served directly from disk. The URLs passed to Vite are now percent encoded
to properly handle asset paths that may contain unsupported URL characters.
When using the esbuild-based browser application builder, the console build stats output
will now show the estimated transfer size of JavaScript and CSS files when optimizations
are enabled. This provides similar behavior to the default Webpack-based builder.
When using a global script (`scripts` option) with the esbuild-based browser application builder,
an attempt to read the script as a relative path from the workspace root will be performed first.
This avoids the need to perform a potentially expensive module resolution attempt for files that
are directly available and also ensures the relative paths are given priority over any potential
modules with the same name. This matches prior behavior that also preferred relative paths.
This provides a minor performance benefit for the generation of the Chrome sourcemap ignorelist
generation. Memory is shared were possible and string searching is reduced in certain cases.
When using the esbuild-based browser application builder with the Vite-based development
server on Windows, source asset paths were previously not normalized prior to being included
in request URLs. This could result in invalid asset request URLs due to invalid path
segment separators.
When using the esbuild-based build system with the service worker enabled, binary assets were
unintentionally being hashed with the assumption of UTF-8 encoding. The assets are now hashed
directly to ensure correct output hashes.
When using the esbuild-based browser application builder with CLI caching enabled, TypeScript's `incremental`
option will also be enabled by default. A TypeScript build information file will be written after each build and
an attempt to load and use the file will be made during compilation setup. Caching is enabled by default within
the CLI and can be controlled via the `ng cache` command. This is the first use of persistent caching for the
esbuild-based builder. If the TypeScript `incremental` option is manually set to `false`, the build system will
not alter the value. This can be used to disable the behavior, if preferred, by setting the option to `false` in
the application's configured `tsconfig` file.
NOTE: The build information only contains information regarding the TypeScript compilation itself and does not
contain information about the Angular AOT compilation. TypeScript does not have knowledge of the AOT compiler
and it therefore cannot include that information in its build information file. Angular AOT analysis is still
performed for each build.
To allow lower overhead trial of the developer preview of the esbuild-based builder system,
the development server now has an option to force the usage of the esbuild-based
build system while still retaining the default Webpack-based build system for the
`build` command. The `forceEsbuild`/`--force-esbuild` option can be added to the
`angular.json` options for the `serve` target or used on the command line, respectively.
The `browser-esbuild` builder will be used to build the application using the options
specified by the server configuration's `browserTarget` option. Unsupported build options
will be ignored. If using a third-party builder, a warning will be issued but the build
will still be attempted. Third-party builder usage in this context is considered
unsupported and may result in unexpected behavior or build failures.
