This commit bundles the Critters library to ensure compatibility with Nodeless environments. Additionally, all licenses for bundled libraries, including Critters, are now included in the package. This helps maintain compliance with open-source license requirements.
The `@angular/compiler-cli/private/tooling` package export is now used instead
of the main package export to allow cleanup of the compiler-cli package. This
secondary export has existed for several major versions.
The `browserTarget` option has been removed as part of the refactoring process. This option was part of a private API and is no longer used. Projects relying on this option should migrate to using the `buildTarget` option.
BREAKING CHANGE: The `browserTarget` option has been removed from the DevServer and ExtractI18n builders. `buildTarget` is to be used instead.
The logic that automatically added the `@angular/localize/init` polyfill has been removed.
BREAKING CHANGE: The `@angular/localize/init` polyfill will no longer be added automatically to projects. To prevent runtime issues, ensure that this polyfill is manually included in the "polyfills" section of your "angular.json" file if your application relies on Angular localization features.
Now that style elements within templates are processed as inline component
styles, the style contents should only be considered CSS. This ensures
consistent behavior prior to when style elements were processed. It also ensures
that the styles will function as expected in JIT mode where template styles
cannot be preprocessed and must be written in a browser supported language.
If an application has JavaScript files that are sourced directly from disk,
the extraction would previously fail due to the i18n extractor only able
to access the in-memory generated JavaScript files. The extractor can now
access both memory and disk-based JavaScript files.
The Node.js inspector will now only be imported if SSR is enabled and
the `inspect` option is used. This prevents potential failures when a
custom Node.js binary build is used that has not enabled inspector usage.
While this is not common, loading the inspector on demand is a minimal
change that also avoids loading code that will not be used for the majority
of development server usage.
The internal "buildApplicationInternal" function is only used by several consumers that
require writing the output files to disk. One, `browser-esbuild`, directly writes
to the disk. The two experimental unit test builders also have unique requirements
and also directly write. This leaves only the main `application` builder that relies on the
internal file writing functionality of `buildApplicationInternal`. To avoid unneeded
logic for the other usages (`dev-server`, `extract-i18n`, unit testing, etc.), the
disk writing logic is now elevated to the `application` build itself. The internal
function will now always provide the output files within the result objects generated
from a successful build. This also removes the need for the other usages to specify
that files should not be written to disk.
If the TypeScript `incremental` option is explicitly set to `false`, the
`application` builder will no longer attempt to enable and use incremental
compilation mode via stored TypeScript build file information. This prevents
an potential build time error that would otherwise occur due to the `tsBuildInfoFile`
option being set without the `incremental` option.
Behavior remains the same if the option is not present or set to `true`.
This addresses a bug where `@import url()` statements with remote CSS files (ending in .css) caused build errors when Tailwind was present. The issue arised from incorrect handling of remote URLs by the stylesheet plugin, which treated them as local files. This fix ensures proper handling of remote CSS imports.
Closes#28113
The Sass rebasing lexer was incorrectly checking for a comma in certain
cases previously. This has now been corrected and url usage that immediately
follows a comma within a rule will now be extracted as expected.
The application builder now provides structured output types to its internal
consumers. The architect builders themselves and the programmatic API is
not changed. These output result types allow for the development server to
receive additional information regarding the build and update the active
browser appropriately. This functionality is not yet implemented but the
additional result types provide the base infrastructure to enable future
features. The result types also allow for reduced complexity inside other
builders such as i18n extraction and the browser compatibility builder.
The usage is not yet fully optimized and will be refined in future changes.
When adjusting URLs to support explicit external dependencies when using Vite,
the workaround will now account for the presence of a base HREF value within
the specifier. Vite will automatically add the base HREF as a prefix to the
path when specified. This previously resulted in invalid specifiers due to
the partial removal of the Vite specific `@id` path prefix.
When using the application builder, a `loader` import attribute is now available
for use with import statements and expressions. The presence of the import
attribute takes precedence over all other loading behavior including JS/TS and
any `loader` build option values. This allows per file control over loading
behavior. For general loading for all files of an otherwise unsupported file
type, the `loader` build option is recommended.
For the import attribute, the following loader values are supported:
* `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
Unfortunately, at this time, TypeScript does not support type definitions
that are based on import attribute values. The use of `@ts-expect-error`
or the use of individual type definition files (assuming the file is only
imported with the same loader attribute) is currently required.
Additionally, the TypeScript `module` option must be set to `esnext` to
allow TypeScript to successfully build the application code.
As an example, an SVG file can be imported as text via:
```
// @ts-expect-error TypeScript cannot provide types based on attributes yet
import contents from './some-file.svg' with { loader: 'text' };
```
When using the development server and a file that is referenced from a Node.js
package with a loader attribute, the package must be excluded from prebundling
via the development server `prebundle` option. This does not apply to relative
file references.
When the sourceMaps are enabled they are generating some files that are computed by the budget stats. Now the method `generateBudgetStats` skip when the file is undefined.
The `ansi-color` and `ora` dependencies have been replaced with `listr2`.
This package provides both color and spinner capabilities and further
reduces the dependency count. This also aligns the dependencies with
the `@angular/cli` package with already uses `listr2`. The spinner also
now will not overwrite console output that happens to be written while
the spinner is active. Instead, the output will be written after the
spinner task is complete.
When using a WASM file on Node.js via SSR/SSG/etc. the path for the `readFile`
call will now be based on the location of the script using the WASM file
instead of the current working directory.
This change also adds a general Node.js WASM E2E test via prerendering.
The Node.js types (`@types/node`) now contains the information for the `Response`
class and the global `fetch` function. The `Response` object is also globally
accessible in all versions of Node.js supported by the Angular CLI. This removes
the need to depend directly on the `undici` package.
The `undici` package is still used for unit-testing and remains as a development
dependency.
The isolated modules transpilation option that was recently introduced is
currently disabled when source maps are enabled. TypeScript has two mutually
exclusive options that can be used to check for source map usage. Both of
these options (`sourceMap` and `inlineSourceMap`) are now checked to determine
if the direct transpilation optimization can be used.
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
