This introduces support for `--watch` when using the application
builder. It's tested as far as the relevant test case is concerned.
But I wouldn't be surprised if there's still some rough corners.
Previously, the testing module was split into its own entrypoint but
then never loaded. Now it's just left in the overall polyfill bundle.
The bug wasn't caught by the existing test coverage, so this adds a
new test that ensures that fakeAsync works.
Cleaning up the Karma `files` list also removes the noisy "no file
matched the pattern worker-*.js" warnings that were previously generated
for test suites that don't include web worker sources.
Adds a new "builderMode" setting for Karma that can be used to switch
between webpack ("browser") and esbuild ("application"). It supports a
third value "detect" that will use the same bundler that's also used for
development builds.
The detect mode is modelled after the logic used for the dev-server builder.
This initial implementation doesn't properly support `--watch` mode or code
coverage.
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.
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.
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.
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.
With the structured build results available, the Jest builder can now more
easily write only the needed files to a temporary location. This reduces
the need to assume build directory output structure and reduces the amount
of potential filesystem calls. The temporary files are also now written
into a UUID subdirectory within the existing `dist/test-out` location.
This allows for multiple projects to be tested concurrently without
overwriting each other.
With the structured build results available, the WTR builder can now more
easily write only the needed files to a temporary location. This reduces
the need to assume build directory output structure and reduces the amount
of potential filesystem calls. The temporary files are also now written
into a UUID subdirectory within the existing `dist/test-out` location.
This allows for multiple projects to be tested concurrently without
overwriting each other.
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.
This commit reduces the maximum number of workers to the available CPUs minus 1. This adjustment ensures that some resources are left for the main thread, preventing it from being starved of CPU cycles.
Several smaller code changes to improve type information and remove now
unneeded code structures based on improvements to both Node.js, TypeScript,
and underlying dependencies.
Due to bazel rules_nodejs caching, several additional `JSON.parse` usages were not
caught in the first set of fixes. These have now been addressed. Also,
the `must-use-promises` rule has been patched to match the behavior of the
`@typescript-eslint/no-floating-promises` for consistency.
The bazel option `suppressTsconfigOverrideWarnings` was also removed from the
`tsconfig` as it is a no-op and was previously used for now removed feature.
Test files are currently excluded from the `JSON.parse` rule to avoid large
changes to test code.
The TypeScript `isolatedModules` option is now enabled for all TypeScript
code within the repository. As a result, all packages will now be built
with the option enabled. This does not affect projects created with the CLI
and is only related to the building of the actual Angular CLI code.
The `isolatedModules` option ensures that code can be emitted without the
TypeScript typechecker and allows tools other than TypeScript to potentially
be used. Code was updated to correct all errors after the option was enabled.
Additionally, some early code fixes were done to add function and accessor
return types to prepare for future `isolatedDeclarations` usage. More changes
would be needed to consider turning on `isolatedDeclarations`, however.
The Node.js `os.availableParallelism` API now provides more accurate values
when used within containers such as many CI environments. This provides a
better default when using resource limited CI setups. The value is still
set to a maximum default of four. However, the `NG_BUILD_MAX_WORKERS`
environment variable can be used to set the value to an explicit value
if required.
The `istanbul-lib-instrument` package provides the required functionality needed
to instrument code for test coverage within the context of the Angular CLI.
Since the build pipeline already contains a customized babel preset, this package
can be integrated directly into the pipeline.
This reduces the number of dependencies required for `@angular-devkit/build-angular`
including the deprecated `inflight` package.
In this commit, the custom implementation of a promise-based setTimeout function has been replaced with the native Node.js setTimeout function, which now returns a promise.
Updates for all angular.io links to the new angular.dev domain. Additionally, adjustment to new resources where the equivalent does not exist on the new site (e.g. Tour of Heroes tutorial)
This commit introduces an `--inspect` option to the dev-server, enabling debugging of server-side code when using SSR or SSG. This option is equivalent to `node --inspect=[[host:]port]`.
Usage examples:
```
$ ng serve --inspect
$ ng serve --inspect 9999
$ ng serve --inspect localhost:9999
```
Closes: #27773
Newly generated projects will now use ECMAScript standard class field behavior by default.
If the legacy TypeScript behavior is required for a new project the `useDefineForClassFields`
TypeScript option can be set to `false` within the application's `tsconfig`. This should
be uncommon, and if needed, it is recommended to adjust code to match standard behavior where
possible.
