Runs all existing karma tests twice: Once in an environment that uses the
application builder and once in one that uses the browser builder. The
general approach is taken from the dev server tests.
This is in preparation for supporting the application builder for karma tests.
We recently introduced the ability to pass object values from the
command line (#28362). @clydin noticed that the initial behavior
didn't work well for `--define`: It completely replaced all values
even if just one of multiple defines is specified.
This updates the architect to support merging of object options.
If both the base option (e.g. from `angular.json`) and the override
(e.g. from a CLI `--flag`) are objects, the objects are merged.
See: https://github.com/angular/angular-cli/pull/28362
I often struggle with spacing around block comments, so I've decided to add the `lines-around-comment` lint rule to help manage this.
For more details, see the https://eslint.style/rules/js/lines-around-comment
Refactored the `CommonEngine` API import path to remove Node.js dependencies from the `@angular/ssr` main entry-point.
BREAKING CHANGE:
The `CommonEngine` API now needs to be imported from `@angular/ssr/node`.
**Before**
```ts
import { CommonEngine } from '@angular/ssr';
```
**After**
```ts
import { CommonEngine } from '@angular/ssr/node';
```
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.
These server tests frequently fail due to timeouts. Despite efforts, the root cause has not yet been identified, so they are being marked as flaky to prevent blocking the pipeline while further investigation continues.
BREAKING CHANGE: The deprecated `fileBuffer` function is no longer available. Update your code to use `stringToFileBuffer` instead to maintain compatibility.
**Note:** that this change does not affect application developers.
The `resourcesOutputPath` option from the browser builder is supported as of 18.2.
The unsupported warning is now removed. The warning logic has also been consolidated
now that there are only several warnings left.
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 implementation of the `browser-esbuild` builder is now a small wrapper around the
`application` builder. The custom file writing code is no longer required with the availability
of the additional output path options for `application` builder. This also allows the internal
`browser-esbuild` programmatic interface to retain its architect-based signature.
Previously, when a select or checkbox prompt failed validation, it was bypassed, preventing users from correcting their input. This commit ensures that when validation fails, the prompts are re-displayed, allowing users to make the necessary corrections. This improves the user experience and helps avoid unintended selections.
Closes#28189
The `@typescript-eslint/eslint-plugin` package has been updated to v8.0.1.
With new major versions of the package, additional rules are added to the
default recommended list. Several such new rules have been disabled to
minimize the code changes to update the package. Several minor type only
fixes were however included to reduce the number of disabled rules.
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.
