`compileComponents` is not necessary when using the CLI (as the templates are inlined) and just adds boilerplate code. So we can remove it from the test schematic and make it independent from `async/await` (only place we would have it in the CLI generated code, and in most Angular apps).
G3 is now using RXJS version 7 which makes it possible for the CLI to also be updated to RXJS 7.
NB: this change does not remove all usages of the deprecated APIs.
Closes#24371
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 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.
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.
The dev-infra build tooling is now decoupled from `ng-dev`. This will
make it easier to update `ng-dev` without necessarily needing to upgrade
the whole build system, Bazel etc. This is useful when e.g. new release
tool features have been added and should also be ported to active LTS
branches.
Prepares the `@angular-devkit/build-webpack` package for the eventual change of enabling the
TypeScript `useUnknownInCatchVariables` option. This option provides additional
code safety by ensuring that the catch clause variable is the proper type before
attempting to access its properties. Similar changes will be needed in the other
packages in the repository prior to enabling `useUnknownInCatchVariables`.
Since Angular 8, the CLI has transformed decorator metadata to a form that can be used by the Angular dependency injector without the TDZ limitations of Typescript's decorator metadata emit feature.
As a result, a JIT application compiled with the CLI no longer requires the reflect metadata polyfill that was provided by `core-js`.
This polyfill was also the last remaining usage of the `core-js` package within `@angular-devkit/build-angular` which allows the `core-js` package to also be removed.
Refs: https://github.com/angular/angular-cli/pull/14473 & https://github.com/angular/angular/pull/37382
BREAKING CHANGE: Reflect metadata polyfill is no longer automatically provided in JIT mode
Reflect metadata support is not required by Angular in JIT applications compiled by the CLI.
Applications built in AOT mode did not and will continue to not provide the polyfill.
For the majority of applications, the reflect metadata polyfill removal should have no effect.
However, if an application uses JIT mode and also uses the previously polyfilled reflect metadata JavaScript APIs, the polyfill will need to be manually added to the application after updating.
To replicate the previous behavior, the `core-js` package should be manually installed and the `import 'core-js/proposals/reflect-metadata';` statement should be added to the application's `polyfills.ts` file.
With this change we update the TypeScript compilation target to `ES2020` for both new and existing projects. This is because all browsers that Angular supports (https://angular.io/guide/browser-support) support `ES2020` features without the need for polyfills.
