The instructions for when optional migrations are present within an updated
package have been adjusted. A sentence has been added to mention that
optional migrations can be executed after the update process if preferred
and can be skipped for now.
The ng update package group list now contains the newly introduced
`@angular/build` package which contains the esbuild/Vite-based
build system. The group list ensures that all relevant direct
project dependencies are update as group when `@angular/cli` itself
is updated.
With the `application` builder already within the new `@angular/build` package,
the `extract-i18n` builder with application builder support is now also contained within this package.
Only the application builder aspects of `extract-i18n` have been moved.
The compatibility builder `browser-esbuild` is not supported with `@angular/build:extract-i18n`.
The existing `extract-i18n` builder found within `@angular-devkit/build-angular` should continue to be used for both the
Webpack-based `browser` builder and the esbuild-based compatibility `browser-esbuild`
builder. To maintain backwards compatibility, the existing `@angular-devkit/build-angular:extract-i18n`
builder continues to support builders it has previously.
No change to existing applications is required.
The `@angular/build` package has been introduced to house the esbuild/Vite-based
build system that was newly introduced as stable in v17. The existing
`@angular-devkit/build-angular` package will continue to contain the Webpack-based
build system and to ensure backwards compatibility it will also provide aliases
for the esbuild/Vite-based build system. The changes here are the first stage
of the builder transition and moves the `application` builder into the new package.
The application builder can now be accessed when this package is installed directly
via `@angular/build:application`.
No changes are required for existing projects.
This command lacked practical utility.
BREAKING CHANGE: The `ng doc` command has been removed without a replacement. To perform searches, please visit www.angular.dev
To prevent `JSON.parse` errors triggered by Byte Order Marks (BOMs) in package.json files, the `readJson` tree method is now utilized for more reliable BOM handling.
Closes#27052
This is a new `@angular-devkit/build-angular:web-test-runner` builder which invokes Web Test Runner to execute unit tests in a real browser.
The implementation calls `application` builder under the hood with some option overrides build the application to a temporary directory and then runs Web Test Runner on the output. This set up is still minimal, but sufficient to run and pass tests in the generated `ng new` application.
The `schema.json` file is directly copied from the `karma` builder, since this is intended to serve as a migration target for users coming from Karma. Most of the options don't actually work yet, which is logged when they are used.
The most interesting part of this change is configuring Jasmine to execute in Web Test Runner. This is done through the `testRunnerHtml` option which allows us to control the HTML page tests are executed on. We use `test_page.html` which very carefully controls the loading process. I opted to make a single `<script type="module">` which dynamic imports all the relevant pieces so the ordering can be directly controlled more easily. This is better than trying to manage multiple `<script>` tags and pass data between them. Ideally everything would be bundled into a single entry point, however this is not feasible due to the way that ordering requirements do not align with typical `import` structure. Jasmine must come before polyfills which must come before the runner which invokes user code. In an ideal world, this ordering relationship would be represented in `import` statements, but this is not practically feasible because Angular CLI doesn't own all the files (`./polyfills.js` is user-defined) and Jasmine's loading must be split into two places so Zone.js can properly patch it.
`jasmine_runner.js` serves the purpose of executing Jasmine tests and reporting their results to Web Test Runner. I tried to write `jasmine_runner.js` in TypeScript and compile it with a `ts_library`. Unfortunately I don't think this is feasible because it needs to import `@web/test-runner-core` at runtime. This dependency has some code generated at runtime in Web Test Runner, meaning we cannot bundle this dependency and must mark it as external and dynamic `import()` the package at runtime. This works fine in native ESM, but compiling with TypeScript outputs CommonJS code by default (and I don't believe our `@build_bazel_rules_nodejs` setup can easily change that), so any `import('@web/test-runner-core')` becomes `require('@web/test-runner-core')` which fails because that package is ESM-only. The `loadEsmModule` trick does work here either because Web Test Runner is applying Node module resolution at serve time, meaning it looks for `import('@web/test-runner-core')` and rewrites it to something like `import('/node_modules/@web/test-runner-core')`. In short, there is no easy syntax which circumvents the TypeScript compiler while also being statically analyzable to Web Test Runner.
The dynamically compiled ESM import helper is now cached to prevent the need
to recompile the helper function everytime a load ESM helper call is made.
This helper is currently used to workaround dynamic import limitations with
the TypeScript compilation output. Once the build process is updated, it will
no longer be required.
