The `declaration` TypeScript option has been removed from the default generated
`tsconfig` for new projects. This option was explicitly set to `false`. However,
the default value for the option is already `false`.
Also, the `sourceMap` option has been removed. Source map generation is controlled
by the build options and not the TypeScript configuration.
As 3acb7768317bb05a9cd73fa64e081b5ca0326189 introduced an optimization for projects that use `isolatedModules`,
this commit makes projects generated with `ng new` use this option by default.
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)
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.
The `bundler` TypeScript resolution mode is now the default for all newly created
Angular CLI projects. This mode allows TypeScript to read and use any package.json
`exports` and `imports` fields found within packages including the Angular workspace.
Unlike the `node16` option value, this value does not require the use of file extensions
for each import and does not require modification of all existing application code to
use. The TypeScript language service also benefits from this option by allowing import
auto-discovery to leverage any `exports` defined for a package. This is particularly
useful for packages such as `@angular/material` which makes extensive use of secondary
package exports.
Additional information regarding this resolution mode can be found here:
https://www.typescriptlang.org/tsconfig#moduleResolution
This commit enables `skipLibCheck` in new workspaces which is now recommanded by TypeScript. When enabled, type checking of declaration files is skipped as rather than doing a full check of all `d.ts` files, TypeScript will type check the code you specifically refer to in your app’s source code.
See: https://www.typescriptlang.org/tsconfig#skipLibCheck
The `esModuleInterop` TypeScript option is a TypeScript recommended option that ensures that TypeScript
emits compliant ESM code when transforming namespace and default imports. This is important for new projects
because they now use the `application` builder which emits full ESM code. Not using this option with certain
third-party packages (e.g., `moment`) can result in build warnings and the potential for runtime failure. For existing
applications that are considering migrating, information pertaining to this situation will be available within
the documentation.
Since the `allowSyntheticDefaultImports` is implied and automatically enabled when `esModuleInterop` is enabled,
the previous option has been replaced with this one.
Reference: https://www.typescriptlang.org/tsconfig#esModuleInterop
This commit updates the `ng generate application` to use the esbuild `application` builder. This also updates the schematics to support both `browser` and `application` builders.
BREAKING CHANGE: `rootModuleClassName`, `rootModuleFileName` and `main` options have been removed from the public `pwa` and `app-shell` schematics.
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`.
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`.
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.
By using the `strings` re-export from `@angular-devkit/schematics` instead of from `@angular-devkit/core`,
the number of imports from `@angular-devkit/core` has been reduced and lowers the direct dependency count
for many of the individual schematics.
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.
With this change we update the validation of the libraries and application projects names to fully allow characters that make a valid NPM package name. http://json.schemastore.org/package has been used as reference.
We also remove validators that are no longer needed.
Closes#11051
With this change we sync workspace and library schematic dependencies using Renovate. We do this to avoid having to keep these in sync by hand.
We could have used TypeScripts' `resolveJsonModule` to make the `latestVersion` object typesafe. But `ts_library` doesn't support JSON inputs.
This is not the first time, that this package caused a breaking change in a minor version, were it drops support for older `jasmine-core` versions.
Related to #21326
All TypeScript files have been updated to pass the new eslint-based linting checks. eslint compatible disabling comments have also been added in place of the previous tslint comments.
With this change we update the TypeScript target of server compilation unit for new projects.
- E2E target has been update from `es2018` to `es2019`
- Browser target has been update from `es2015` to `es2017`
- Server target has been update from `es2016` to `es2019`
