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.
BUILD files for each package have had outdated glob excludes removed.
Additionally, some src args have been reduced to a single file where possible.
The root bazel ignore file has also been expanded to include all node module
directories in each package. The ignore file does not appear to currently support
globs so each path has been individually specified.
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.
The internal emit strategy for the TypeScript/Angular compiler has been adjusted to prefill
the memory cache during the initial phase of the build. Previously each file was emitted
during the bundling process as requested by the bundler. This change has no immediate effect
on the build process but enables future build performance improvements.
`UpdateBuffer` only supports UTF-8 encoded files, which causes schematics to emit corrupted binary like files such as images.
This commit also introduce an errors when the `UpdateRecorder` is used for non UTF-8 files.
Closes#25174
When using the esbuild-based browser application builder, CommonJS file warnings were incorrectly being
issued for relative file imports. The CommonJS warnings are only intended to be generated for node module
imports.
When using the esbuild-based browser application builder with the development server, the incoming
URL for the index HTML may contain search parameters or other URL elements that can cause the index
HTML content to not be found or processed incorrected by the development server. These elements are
cleaned prior to comparison and the original URL is not longer passed to Vite to avoid unneeded
Vite specific processing of the content.
When using the esbuild-based browser application builder with a `url()` in a stylesheet that uses
that Webpack-specific tilde prefix, a note will be added to the resolution error providing additional
information regarding the removal of the tilde.
When using the esbuild-based browser application builder with the development server, an
underlying Vite server is used. The Vite server currently does not support glob-based entries
for the proxy configuration. They must either be prefix strings or regular expressions. The
Webpack-based development server, however, does support globs. To remove the need to have
different proxy configuration files for the two servers, the entries will now be normalized
to regular expressions when using the Vite server. This allows existing proxy configurations
to work without modification.
When using the esbuild-based browser application builder with the development server,
the `baseHref` build option will now be properly propagated to the underlying Vite
server.
esbuild currently has a defect involving self-referencing a class within a static code block or
static field initializer. This is not an issue for projects that use the default browserslist as these
elements are an ES2022 feature which is not support by all browsers in the default list. However, if a
custom browserslist is used that only has newer browsers than the static code elements may be present.
This issue is compounded by the default usage of the tsconfig `"useDefineForClassFields": false` option
present in generated CLI projects which causes static code blocks to be used instead of static fields.
esbuild currently unconditionally downlevels all static fields in top-level classes so to workaround the
Angular issue only static code blocks are disabled here.
Fixes#25127
When using the esbuild-based browser application builder, non-injected global styles and scripts
were unintentionally being output with filenames that contain a hash. This can prevent the filenames
from being discoverable and therefore usable at runtime. The output filenames will now no longer
contain a hash component which matches the behavior of the Webpack-based builder.
This commit fixes and issue were standalone applications would fail during runtime because the `@angular/compiler` is not available.
We now add the `@angular/compiler` as part of the bundle when JIT mode is enabled.
The status of the esbuild-based browser application builder has been changed to developer
preview. Warning messages for unsupported options are now updated to reflect this change.
While currently esbuild is not use to bundle server bundles, it will in the future. This commit adds a check for the `@angular/platform-server/init` entry-point to be excluded from advanced optimizations.
Vite inlines the source map as part of content (ba62be40b4/packages/vite/src/node/server/send.ts (L59-L63)) with no option to disable this behaviour. While this is improves performances when Vite is used without prebundling. When using prebundling this is causes an overhead as the response can grow drastically, in some cases over 50mb.
This configures polyfills to set up the environment before executing Jest tests. We need to do three things:
1. Set the global `jest` symbol. Jest executing in ESM does not provide the `jest` global and users are expected to import from `@jest/globals` or `import.meta.jest`. Zone.js is not compatible with this yet, so we need to manually define the `jest` global for Zone to read it.
2. Run user polyfills, (typically including `zone.js` and `zone.js/testing`). Zone reads the `jest` global to recognize the environment it is in and patch the relevant functions to load fake async properly. Users can override this part if they are building a Zoneless application or have custom polyfills for other browser functionality.
3. Initalize `TestBed`. This configures the `TestBed` environment so users don't have to manually configure it for each test file.
Ordering is very important for these operations, which complicates the implementation somewhat. `zone.js/testing` does not include an import on `zone.js`, meaning there was no guarnatee the bundler would sort their executions in the correct order. Similarly, `zone.js` does not import anything from Jest, so it is not trivial to inject the `globalThis.jest = import.meta.jest;` line before Zone loads. Even setting polyfills to `[jestGlobal, 'zone.js, 'zone.js/testing', initTestBed]` doesn't work because code splitting rearranges the order of operations in an incompatible way. Instead, these are implemented as distinct entry points in `browser-esbuild` with Jest's `--setupFilesAfterEnv` option executing them in the correct order.
Ideally, we could drop the global initialization altogether once Zone.js knows to look for `import.meta.jest` in an ESM context. Also we might be able to reduce down to a single polyfills entry point if `zone.js/testing` had an import on `zone.js` to apply correct ordering.
