This change fixes an issue where calling the universal schematic on an application with existing `BrowserModule.withServerTransition` will cause an additional `.withServerTransition` call to be added.
With this change we now remove the previous `withServerTransition` call to avoid misconfiguration.
Closes#24563
When performing a release via the dev-infra `ng-dev` tooling, the release
builds for the packages that will be published are now performed using bazel.
Prior to this, the release builds were performed using a custom build script
that programmatically invoked TypeScript APIs. The Bazel build and discovery
process for the releasable packages is performed by a script that is based on
the scripts from components and framework repositories. Several small modifications
were performed to match the behavior and structure of the cli repository:
* Use of `packages` as the source root in the bazel query
* Use of `pkg_npm` rule in the bazel query
* Partial transition to native Node.js `fs` APIs instead of `shelljs`
* Directory creation per package when copying output (supports multiple package scopes)
* Copying of archives (tgz) for each package
The snapshot and local build capabilities are not modified as part of this change
but will be merged in a followup as part of a larger transition to use bazel
throughout the package build process.
This commits add a schematic to generate Karma and Browserlist files which since version 15 are no longer generated by default. This schematic should be used to generate these files when further customisation is needed.
Usage
```
ng generate config karma
ng generate config browserlist
```
Closes#24294
A schematic has been added that will allow the generation of environment files
for all existing configurations within a project. The `fileReplacements` option
will also be setup to allow the replacement of the appropriate environment file.
Environment files themselves do not provide any special behavior beyond
that of other application TypeScript files and rely on the `fileReplacements`
option for build-time behavior. The schematic will skip generating environment files
for configurations that already have an appropriately named environment file. The
`fileReplacements` option addition will also be skipped if an appropriate entry
is already present.
These async methods are a replacement for the Observable based `runSchematicAsync` and `runExternalSchematicAsync` methods.
DEPRECATED:
The Observable based `SchematicTestRunner.runSchematicAsync` and `SchematicTestRunner.runExternalSchematicAsync` method have been deprecated in favor of the Promise based `SchematicTestRunner.runSchematic` and `SchematicTestRunner.runExternalSchematic`.
It is unnecessary now that the spec uses `runInInjectionContext`
The resolver spec does not have this issue as the import was missing in the spec in the first place.
With this change we add the `vendorChunk` option in the server builder. This option should only be used in development as it is intended to be used to improve the incremental re-build time.
This improves the rebuild time as Webpack will have less modules to analyse during a change in the application. Below, we can see the impact this change has in a `ng new` application.
Without vendor chunking
```
$ ng run ssr-vendor:server:development --watch --no-vendor-chunk
Build at: 2022-11-14T08:42:27.089Z - Hash: 0325905b63e43ddb - Time: 15357ms
Build at: 2022-11-14T08:42:37.565Z - Hash: 05cb180a02524656 - Time: 2498ms
Build at: 2022-11-14T08:42:40.325Z - Hash: c5a6996ed1924088 - Time: 1862ms
Build at: 2022-11-14T08:42:43.043Z - Hash: 92ce99f38a769c19 - Time: 1516ms
```
With vendor chunking
```
$ ng run ssr-vendor:server:development --watch --vendor-chunk
Build at: 2022-11-14T08:43:13.631Z - Hash: 28bdfea879d01a31 - Time: 15561ms
Build at: 2022-11-14T08:43:19.396Z - Hash: cc95e2b6cb403111 - Time: 1705ms
Build at: 2022-11-14T08:43:21.296Z - Hash: 204138490668a16c - Time: 848ms
Build at: 2022-11-14T08:43:23.835Z - Hash: 4fa294b261917944 - Time: 824ms
```
Functional guards and resolvers were introduced in the Angular router in v14.2.
This commit adds the ability to generate functional router guards by
specifying `--guardType` instead of `--implements`. These guards are also
accompanied by a test that includes a helper function for executing the
guard in the `TestBed` environment so that any `inject` calls in the
guard will work properly. Functional resolvers are generated by adding
the `--functional` flag.
The `CanMatch` guard was added in v14.1 but not added
to the list of possible interfaces to implement.
This commit adds `CanMatch` to the list of possible
interfaces to implement. It has the same type imports
as the CanLoad interface.
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`.
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 strictNullChecks in enabled in TS compiler, the following files
cause some failures in certain environments. Fix these failures.
Also update outdated goldens.
`@angular-devkit/build-angular` now has a built in Karma config. Users can still create their own Karma configuration if they want to override the default configuration.
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
});
```
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
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 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.
