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 2kB/4kB warning/error thresholds for any component style within an application
has now been increased to 4kB/8kB for warnings/errors respectively. This allows for
more complex styles within a component while also reducing the likelihood of the budget
rule being disabled or removed. The new limits still provide diagnostics for extreme
size cases such as accidentally importing all Bootstrap or Material styles into an
individual component. Such instances are a primary use case for the budget.
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 logic that automatically added the `@angular/localize/init` polyfill has been removed.
BREAKING CHANGE: The `@angular/localize/init` polyfill will no longer be added automatically to projects. To prevent runtime issues, ensure that this polyfill is manually included in the "polyfills" section of your "angular.json" file if your application relies on Angular localization features.
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.
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.
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 SSR schematic was previously only checking for the application build found
within the `@angular-devkit/build-angular` package which is only an alias to the
actual builder found in the `@angular/build` package. Both aliased and direct
usages are now checked when executing the schematic.
The optional migration selection prompt shown during an interactive
`ng update` will now show the name of the migration which can be used
to manually run the update at a later time as well as a documentation link
if present for the migration.
The description for the optional application builder migration has been adjusted
to include an update adev link as well as a shorter first sentence which is used
as the content for the optional migration selection prompt.
Ensure that file sizes are consistently formatted using decimal byte units, adhering to the International System of Units (SI) convention. This aligns with clarity and standardization across the project.
- Kilobyte (kB): 10^3 bytes (1000 bytes)
- Megabyte (MB): 10^6 bytes (1,000,000 bytes)
- Gigabyte (GB): 10^9 bytes (1,000,000,000 bytes)
Closes: #27580
The description for the optional application builder migration is shown
within the optional migration selection prompt. The description is currently
fairly lengthy and can effect readability within a terminal. To improve
readability within the selection prompt, the description has been slightly
reworded and shortened.
The application migration schematic will now attempt to detect the usage
of custom postcss plugins within a workspace and install the `postcss` dependency
if required. This will only occur if the migration analysis allows for
the conversion to use the `@angular/build` package instead of the
`@angular-devkit/build-angular` package. Custom postcss configurations will
be detected within the same locations as the build system itself which includes
the workspace root and any project root for the `postcss.config.json` and
`.postcssrc.json` files.
The application migration schematic will now attempt to detect the usage
of Less stylesheets within a workspace and install the `less` dependency
if required. This will only occur if the migration analysis allows for
the conversion to use the `@angular/build` package instead of the
`@angular-devkit/build-angular` package. The Less usage detection may
not detect Less stylesheets within Node.js packages and currently does
not handle the case where a project only has inline Less stylesheets.
More complex analysis may be added in the future. However, a build time
error message will be presented with instructions to install `less` in
these cases if the stylesheet preprocessor is required and not present.
The `buildTarget` option for the `extract-18n` builder will automatically
default to use the `build` target of the containing project. This removes
the need for projects to manually configure the target. New projects will
now be generated without this option in the `angular.json` file.
When using the optional application build system migration, the newly
introduced `@angular/build` package which contains only the new build
system and no Webpack-related dependencies will be directly used when
possible. The migration will check for usage of any other builders from
the `@angular-devkit/build-angular` package. if none are present in the
`angular.json` file (excluding `dev-server` and `extract-i18n`), the
`@angular/build` package will be added as a dependency and used in the
`angular.json` file. The `@angular-devkit/build-angular` package will
then be removed as a dependency. Project usage of karma and/or protractor
will be the most common reasons this part of the migration will not be
performed.
The `deployUrl` option is now supported with the new build system
when using the `application` builder. The migration schematic
no longer needs to remove the option if present.
BREAKING CHANGE: By default, the index.html file is no longer emitted in the browser directory when using the application builder with SSR. Instead, an index.csr.html file is emitted. This change is implemented because in many cases server and cloud providers incorrectly treat the index.html file as a statically generated page. If you still require the old behavior, you can use the `index` option to specify the `output` file name.
```json
"architect": {
"build": {
"builder": "@angular-devkit/build-angular:application",
"options": {
"outputPath": "dist/my-app",
"index": {
"input": "src/index.html",
"output": "index.html"
}
}
}
}
```
Previously, the release process encountered an error due to ts-node's inability to transform `packages/schematics/angular/utility/latest-versions.ts`, resulting in the following error:
```
export const latestVersions: Record<string, string> & {
^^^^^^
SyntaxError: Unexpected token 'export'
at internalCompileFunction (node:internal/vm:73:18)
at wrapSafe (node:internal/modules/cjs/loader:1274:20)
at Module._compile (node:internal/modules/cjs/loader:1320:27)
at Module._extensions..js (node:internal/modules/cjs/loader:1414:10)
at Module.load (node:internal/modules/cjs/loader:1197:32)
at Module._load (node:internal/modules/cjs/loader:1013:12)
at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:202:29)
at ModuleJob.run (node:internal/modules/esm/module_job:195:25)
at async ModuleLoader.import (node:internal/modules/esm/loader:336:24)
at async checkSchematicsAngularLatestVersion (file:///usr/..../git/angular-cli/scripts/release-checks/dependency-ranges/latest-versions-check.mts:9:46)
```
To resolve this issue, we now utilize the `package.json` directly to retrieve dependency versions.
The `assets` directory is confusing for the users and commonly users place "assets" which are not meant to be copied but instead processed by the build system. This causes some files both bundled and copied.
With this change we rename the `assets` directory to `public` and also move the `favicon.ico` inside this newly created directory.
