With this change we refactor the Angular CLI and replace the underlying args parser and command builder. We choose to use Yargs as our parser and command builder of choice. The main advantages of Yargs over other command builders are;
- Highly configurable.
- We already use it in other packages such as the compiler-cli/dev-infra etc..
- Commands and options can be added during runtime. This is a requirement that is needed to support architect and schematics commands.
- Outstanding documentation.
- The possibility to parse args without parser configuration (Free form).
- Commands are built lazily based on the arguments passed.
BREAKING CHANGE:
Several changes in the Angular CLI commands and arguments handling.
- `ng help` has been removed in favour of the `—-help` option.
- `ng —-version` has been removed in favour of `ng version` and `ng v`.
- Deprecated camel cased arguments are no longer supported. Ex. using `—-sourceMap` instead of `—-source-map` will result in an error.
- `ng update`, `—-migrate-only` option no longer accepts a string of migration name, instead use `—-migrate-only -—name <migration-name>`.
- `—-help json` help has been removed.
Closes#20976, closes#16614 and closes#16241
Node.js v12 will become EOL on 2022-04-30. As a result, Angular CLI v14 will no longer support Node.js v12.
BREAKING CHANGE:
Support for Node.js v12 has been removed as it will become EOL on 2022-04-30. Please use Node.js v14.15 or later.
The use of the `@angular-devkit/core` `JsonObject` type is no longer needed to satisfy the type requirements of `@angular-devkit/architect` package builder creation functions.
During the build initialization phase, many paths are converted back and forth between multiple normalized forms. These conversions involve potentially expensive string operations. The majority of the custom path `resolve` function from `@angular-devkit/core` usages have now been removed in favor of the Node.js builtin path functions. This change reduces the need to perform additional string manipulation where possible.
This change is inspired by https://github.com/karma-runner/karma-chrome-launcher/issues/154#issuecomment-986661937 which blocks Karma from launching the browsers until the compilation is complete.
This is needed especially for large applications when using code-coverage where otherwise the users would have to fine-tune several Karma timeouts such as `captureTimeout` for various environments.
Closes#22495
With this change we remove the workaround for fidelity and performance of babel sourcemaps as this is no longer needed as Babel now uses `@ampproject/remapping` to merge sourcemaps.
See https://github.com/babel/babel/pull/14209 for more context.
BREAKING CHANGE:
The deprecated `showCircularDependencies` browser and server builder option has been removed. The recommended method to detect circular dependencies in project code is to use either a lint rule or other external tools.
In some cases unexpected files may be provided which can cause to unsupported or broken behaviour.
One such use-case is users can provide TypeScript files as `scripts` input, this would not be processed by the TypeScript compiler, see: https://github.com/angular/angular-cli/issues/17125 and would cause the build to fail with a an unhelpful error message during optimization as the JS optimizers cannot parse TypeScript input.
BREAKING CHANGE:
`browser` and `karma` builders `script` and `styles` options input files extensions are now validated.
Valid extensions for `scripts` are:
- `.js`
- `.cjs`
- `.mjs`
- `.jsx`
- `.cjsx`
- `.mjsx`
Valid extensions for `styles` are:
- `.css`
- `.less`
- `.sass`
- `.scss`
- `.styl`
This change addresses the `Invalid version: "15.2-15.3"` range error. We previously only handled version ranges for `ios_safari`. Now, we handle such versions for all browsers.
Closes#22606
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.
BREAKING CHANGE:
We now issue a build time error since importing a CSS file as an ECMA module is non standard Webpack specific feature, which is not supported by the Angular CLI.
This feature was never truly supported by the Angular CLI, but has as such for visibility.
This package is deprecated and should not be used. It has always been experimental. All the relevant functionality has been moved into `@angular-devkit/build-angular`.
Currently when making a change while serving a localized application, duplicate
translation warnings appear for every translation id. This fixes that by
replacing the whole translation object with a new one each time translations
are loaded.
fixes#22398
When web-workers are enabled we allowing parsing `new URL` syntax which has the side-effect that Webpack will treat all assets as asset modules (https://webpack.js.org/guides/asset-modules/#url-assets). With this change we remove this inconsistency by disabling the `url` parsing which doesn't effect `new Worker(new URL(...))`.
Previously, we used to delete the temporary emitted JS and map files. However this causes a problem in watch mode, as Webpack will not re-emit these deleted files during the next incremental re-build.
With this change we now delete the entire temporary directory when the process is being terminated instead of a file by file bases.
Closes#22395
After the webpack-dev-server migration to v4, the websocket client was always injected, even if not required. This caused unnecessary 'ws' requests when live-reload and hmr were disabled.
With every build-angular release, previously created cache entries get stale and are no longer used. This causes the cache to keep growing as older files are not purged.
With this change we automatically purge entries that have been created with older version of build-angular and can no longer be used with the current installed version.
Closes#22323
Previously, we enabled the `keepNames` esbuild when mangling was disabled, this caused dead code to be retained because of the transformations that esbuild did to the input.
Input
```js
class foo {}
```
Output
```js
var l = Object.defineProperty,
a = (s, c) => l(s, "name", { value: c, configurable: !0 });
class foo {}
a(foo, "foo");
```
Previously we enabled the `keepNames` esbuild option when mangling was disabled, which is actually not needed to retain the name of symbols but is needed for SSR because Domino relies on the `name` property on functions and classes.
Closes#22354
With this change we enabling Webpack to display additional cache related logs when the `verbose` option is enabled. This is helpful to debug cache misses.
This fixes an issue were in some cases when importing CSS in the compilation using import syntax caused CSS to be extracted which causes a runtime error.
In general this is not something that we fully support since this is a specific webpack features and importing CSS as if they were ES modules not supported by the browsers. However, certain widely using libraries such as Monaco editor depend on this specific Webpack feature.
Note: This non-standard unsupported behaviour will no longer be possible in the next major version.
Closes#22358
Previously, we always consumed the ES2020 entrypoints, which caused issues in environments where the application compilation target is ES2019 or lower and ES2020 is not supported.
This is because we only downlevel code when we target ES5 or below.
- ES5 or below compilations, ES2015 entrypoints are used and their code is downlevelled to ES5.
- ES2019 or below, ES2015 entrypoints are used and no downlevelling is involved.
- ES2020 or later, ES2020 entrypoints are used.
Closes#22270
Previously, we introduced the `ngResource` query to Angular component resources we now use it with `resourceQuery` to differentiate between global and components styles, since in some cases while unlikely a file can be used as a component and global style.
Closes#7245
When `process.versions.webcontainer` is truthy it means that we are running in a StackBlitz webcontainer. `SassWorkerImplementation` uses `receiveMessageOnPort` Node.js `worker_thread` API to ensure sync behavior which is ~2x faster. However, it is non trivial to support this in a webcontainer and while slower we choose to use `dart-sass` which in Webpack uses the slower async path.
In some cases we don't ship certain locales, or they map to files which are named only the language IDs. Example `en-US`, which it's locale data is available from `@angular/common/locales/en.mjs`
Closes#22285
