Some libraries ship spec in node_modules which might result errors such
```
./node_modules/comment-parser/tests/unit/spacer-description-joiner.spec.ts - Error: Module build failed (from ./node_modules/@ngtools/webpack/src/ivy/index.js):
Error: /Users/kkostadinov/Projects/material.angular.io/node_modules/comment-parser/tests/unit/spacer-description-joiner.spec.ts is missing from the TypeScript compilation. Please make sure it is in your tsconfig via the 'files' or 'include' property.
```
This changes removes the need to import `@angular/platform-server/init` in the `main.server.ts` instead we now include this as an entry-point when we are bundling as server bundle.
With this change we remove the need to include the `@angular/localize/init` package as polyfills in `polyfills.ts`, `angular.json` and `main.server.ts`.
Instead when `@angular/localize/init` is included in the TypeScript `types` we add this as entry-point. The `@angular/localize/init` will be added as a parts of the `types` array in a seperate PR to address https://github.com/angular/angular/issues/47677 which is caused by the fact that `@angular/localize/init` types are no longer imported when `@angular/localize/init` is added as a polyfill in `angular.json`.
When using the experimental esbuild-based browser application builder, the Angular diagnostic analysis performed
per rebuild is now reduced to only the affected files for that rebuild. A rebuild will now query the TypeScript
compiler and the Angular compiler to determine the list of potentially affected files. The Angular compiler will
then only be queried for diagnostics for this set of affected files instead of the entirety of the program.
The Sass preprocessor's modern API will generate absolute file URLs for the `sources` field of generated
sourcemaps. These URLs will not be properly processed by esbuild and will not be correctly adjusted to be
relative to the workspace root directory for the built application. To correct this behavior, the Sass
generated sourcemaps are now adjusted to remove the `file:` protocol prefix and to make each path relative
to its input file. This allows esbuild to properly resolve and process the paths.
Prior to this change non relative partial files were not resolved properly. Example we did not try to resolve `@material/button/button` as `@material/button/_button` which caused the compilation to fail.
All analytics is now in the @angular/cli package
BREAKING CHANGE: analytics APIs have been removed without replacement from `@angular-devkit/core` and `@angular-devkit/architect`.
This change updates the analytics collector collector to use GA4 instead of UA. The motivation behind this change is that UA will stop collecting data in 2023.
BREAKING CHANGE:
`analyticsSharing` option in the global angular configuration has been
removed without replacement. This option was used to configure the Angular CLI to access to your own users' CLI usage data.
If this option is used, it can be removed using `ng config --global cli.analyticsSharing undefined`.
When using the experimental esbuild-based browser application builder, initial debug performance profiling
information can now be output to the console by using the `NG_BUILD_DEBUG_PERF` environment variable. When
enabled, duration information for elements of the Angular build pipeline will be shown on the console.
Certain elements marked with an asterisk postfix represent the total parallel execution time and will
not correlate directly to the total build time. This information is useful for both experimentation with
build process improvements as well as diagnosing slow builds.
When generating an app-shell via the app-shell builder, the server application rendering
will now take place within a Node.js Worker. Since the rendering requires the presence of
Zone.js, this change allows for the Zone.js patching to be isolated from the remainder
of the builder and Angular CLI code. This prevents Zone.js from persisting past the needed
render operation. This also allows for a workaround to a Zone.js/Node.js v18 problem where
the TypeScript dynamic import workaround involving the Function constructor to ensure a native
dynamic import expression will cause a failure when running on Node.js v18.10.
Update the build time calculation for the experimental esbuild-based browser application builder to
use the `process.hrtime` time source. The high resolution time provides a more accurate time source
and allows for nanosecond level timings if needed. Currently the console output is rounded to the
nearest millisecond. Future performance monitoring capabilities may leverage the more fine-grained
values.
To further improve incremental rebuild performance of the experimental esbuild-based browser
application builder, the output of JS file babel transformations are now cached in memory by
the input file name and invalidated via the file watching events. This allows an additional
file read per JS input file to be avoided if the file has not changed. Previously the content
of the JS input file was used as the basis of the cache key for the transformation output which
necessitated reading the file. With the file change information available, the content based method
is no longer necessary.
The experimental esbuild-based browser application builder will now support incremental JavaScript
bundling when run in watch mode via the `watch` option. This initial implementation integrates the
esbuild incremental rebuild functionality. TypeScript source file caching has also been added to
improve the rebuild initialization time for the TypeScript and Angular compilation steps.
This initial support is not yet fully optimized and additional work is planned to further improve
the rebuild performance.
A single options object is now used within the experimental esbuild-based browser application builder.
This removes the need to pass around two different options objects with potentially overlapping properties
throughout the build process.
The initial global stylesheet, file replacement, index HTML, and service worker option analysis and cleanup has
now been moved into the `normalizeOptions` helper for the esbuild-based browser application builder. This better
organizes the option related setup steps as well as reduces the amount of code in the main builder source file.
This adds the initial infrastructure to support incremental esbuild rebuilds within the Angular
compiler plugin. Currently, these changes will not yet have an effect on the watch mode rebuild
performance. Integration of esbuild's incremental rebuild mode will be needed within the builder
itself to take advantage of these changes.
The Babel transformation code was mostly duplicated in two places within the esbuild-based browser
application builder. The code has now been extracted into a helper function and used where needed.
The experimental esbuild-based browser application builder now contains initial support for
watching input files and rebuilding the application via the `--watch` option. This initial
implemention is not yet optimized for incremental rebuilds and will perform a full rebuild
upon detection of a change. Incremental rebuild support will be added in followup changes
and will significantly improve the rebuild speed.
The `chokidar` npm package is used to perform the file watching which allows for native file-
system event based watching. Polling is also support via the `--poll` option for environments
that require it.
This change add a Sass File importer that uses Webpack resolvers to better support scenarios when node packages are not stored in node_modules, such as Yarn PNP.
In some cases the build will crash when there is a Sass error due to the fact that the `span` property on the Error instance cannot be cloned.
```
process.nextTick(() => { throw err; });
^
DataCloneError: function StaticClosure() {
} could not be cloned.
at MessagePort.<anonymous> (/node_modules/@angular-devkit/build-angular/src/sass/worker.js:61:41)
```
This commit removes the usage of environment files and `fileReplacements` in new application projects. Previously, the environment files was used to distinguish between a prod build to invoke `enableProdMode`. The `enableProdMode` however needed only for the case of JIT mode in production mode, which is a rare case as JIT mode is recommanded to be used in production.
In the CLI, calling `enableProdMode` is not needed as `ngDevMode` it's set using the minifier.
The test.ts is now included in `@angular-devkit/build-angular` and unless this needs to be customized is no longer needed to be provided.
Default config:
```js
// This file is required by karma.conf.js and loads recursively all the .spec and framework files
import { getTestBed } from '@angular/core/testing';
import {
BrowserDynamicTestingModule,
platformBrowserDynamicTesting
} from '@angular/platform-browser-dynamic/testing';
// First, initialize the Angular testing environment.
getTestBed().initTestEnvironment(BrowserDynamicTestingModule, platformBrowserDynamicTesting(), {
errorOnUnknownElements: true,
errorOnUnknownProperties: true
});
```
Sass modern API provides faster compilations times when used in an async manner.
|Application compilation duration | Sass API and Compiler|
|-- | --|
|60852ms | dart-sass legacy sync API|
|52666ms | dart-sass modern API|
Note: https://github.com/johannesjo/super-productivity was used for benchmarking.
Prior art: http://docs/document/d/1CvEceWMpBoEBd8SfvksGMdVHxaZMH93b0EGS3XbR3_Q?resourcekey=0-vFm-xMspT65FZLIyX7xWFQ
BREAKING CHANGE:
- Deprecated support for tilde import has been removed. Please update the imports by removing the `~`.
Before
```scss
@import "~font-awesome/scss/font-awesome";
```
After
```scss
@import "font-awesome/scss/font-awesome";
```
- By default the CLI will use Sass modern API, While not recommended, users can still opt to use legacy API by setting `NG_BUILD_LEGACY_SASS=1`.
With this change we drop the `polyfills.ts` from new application projects and add the polyfills directly in the `angular.json`. This is possible as now the `polyfills` option accept an array of module specifiers.
This change also fixes another open issue (#14432) which was caused by the missing polyfills file in the library test setup.
Closes#14432
This is the ground work to be able to remove the `polyfills.ts` file which today is primarily used to add `zone.js`.
Usage examples:
```js
polyfills: ['zone.js'],
polyfills: ['zone.js', 'zone.js/testing', 'src/polyfills.ts'],
```
`require.context` is a webpack specific feature which was only needed to support the old Karma test setup.
BREAKING CHANGE: `require.context` are no longer parsed. Webpack specific features are not supported nor guaranteed to work in the future.
Prior to this change specs where found and loaded using Webpack's `require.context` API. The `require.context` is found in the users project `test.ts`. This resulted in a complex and hacky setup especially to filter tests when the `include` builder option is provided, were we had to amend the `test.ts` in memory.
With this change we find all the specs files and add them as part of the main entrypoint.
Closes#23751 and closes#22531
This commit removes the usages of `bundleDependencies` which does not correctly work as webpack will use `require` to import ESM module since we configure the server bundle to be outputted in CJS. Migrating fully to ESM is also currently not viable due to the lack of support from Domino.
Even if full ESM was possible, using this option would have resulted in a runtime overhead as Angular libraries would be linked during runtime instead of compile time.
BREAKING CHANGE:
The server builder `bundleDependencies` option has been removed. This option was used pre Ivy. Currently, using this option is unlikely to produce working server bundles.
The `externalDependencies` option can be used instead to exclude specific node_module packages from the final bundle.
Closes#23905
With this change we replace all usage of `compilation.errors `and `compilation.warnings.push` with `addError` and `addWarning` respectively.
Also, we update the helpers in build-angular to use `WebpackError` from the current compilation to avoid mismatching instances.
With this change we reduce the reliance on the TypeScript target compiler option to output a certain ECMA version. Instead we now use the browsers that are configured in the Browserslist configuration to determine which ECMA features and version are needed. This is done by passing the transpiled TypeScript to Babel preset-env.
**Note about useDefineForClassFields**: while setting this to `false` will output JavaScript which is not spec compliant, this is needed because TypeScript introduced class fields many years before it was ratified in TC39. The latest version of the spec have a different runtime behavior to TypeScript’s implementation but the same syntax. Therefore, we opt-out from using upcoming ECMA runtime behavior to better support the ECO system and libraries that depend on the non spec compliant output. One of biggest case is usages of the deprecated `@Effect` decorator by NGRX and potentially other existing code as well which otherwise would cause runtime failures. Dropping `useDefineForClassFields` will be considered in a future major releases. For more information see: https://github.com/microsoft/TypeScript/issues/45995.
BREAKING CHANGE: Internally the Angular CLI now always set the TypeScript `target` to `ES2022` and `useDefineForClassFields` to `false` unless the target is set to `ES2022` or later in the TypeScript configuration. To control ECMA version and features use the Browerslist configuration.
This commit adds an internal file to export needed symbols from `@angular/platform-server` when building a server bundle. This is needed. This is needed so that DI tokens can be referenced and set at runtime outside of the bundle.
Also, it adds a migration to remove these exports from the users files as otherwise an export collision would occur due to the same symbol being exported multiple times.
