The `deepCopy` utility function previously set its internal tracking symbol property to `undefined` after completion.
However, this still caused the property to exist with a value of `undefined`. Jasmine 4.1 now checks for symbols with
its `toEqual` expectation which resulted in failing tests. The internal tracking symbol property is now removed instead
via `delete`.
In an effort to improve supply chain security, the `NodePackageInstallTask` will now use the package
manager's `--ignore-scripts` option by default. Without the option, all direct and transitive
dependencies would have their scripts executed during the task's package manager installation operation.
The change only affects the package manager behavior controlled by the Schematics `NodePackageInstallTask`.
First-party Angular schematics do not currently require any direct or transitive dependency
`install`/`postinstall` scripts to execute. Only two dependencies within a v14.0 new project would
potentially be affected by this: `nice-napi` (transitive from `piscina`) and `esbuild`. The `nice-napi`
functionality of `piscina` is unused within the Angular CLI with no plans to use it in the future.
Even if it was used, the `install` script runs `node-gyp-build` which would only have an effect
(based on the current version 1.0.2) on platforms that are not Windows, darwin-x64, or linux-x64.
In the event this functionality is eventually used, the Angular CLI could be setup to automatically execute
this particular script for unsupported platforms. For `esbuild`, the `postinstall` functionality
performs an optional native binary bootstrap optimization but would only be performed if not
using Windows or Yarn. As such, it would not be performed for many users regardless of the change in
this commit. If noticeable performance regressions on platforms where the optimization was previously
performed are reported, the script could also be setup to be automatically run by the Angular CLI during
project creation and/or first build.
BREAKING CHANGE: Schematics `NodePackageInstallTask` will not execute package scripts by default
The `NodePackageInstallTask` will now use the package manager's `--ignore-scripts` option by default.
The `--ignore-scripts` option will prevent package scripts from executing automatically during an install.
If a schematic installs packages that need their `install`/`postinstall` scripts to be executed, the
`NodePackageInstallTask` now contains an `allowScripts` boolean option which can be enabled to provide the
previous behavior for that individual task. As with previous behavior, the `allowScripts` option will
prevent the individual task's usage of the `--ignore-scripts` option but will not override the package
manager's existing configuration.
Paths within the `angular.json` file should be relative to the location of the `angular.json` file.
The `ngswConfigPath` option was incorrectly using the current working directory for a base path when
a relative configuration path was specified. Most of the time this would work as a build command usually
is executed from the root of the workspace. However, this may not always be the case and for those cases
the actual workspace root is now used to resolve the full path for the service worker configuration file.
Code related to decoding buffers into strings and parsing content into JSON can now be removed by using the
support provided directly from the Tree instance for the executing schematic.
The schematics `Tree` now contains an additional `readJSON` method that supports directly
reading and parsing the content of a file as UTF-8 JSON with comment support. This avoids the need to manually
decode a Buffer, parse and handle JSON comments within a schematic when JSON content is needed.
If a file path does not exist, an exception will be thrown. While this differs from the semantics of `read`,
it helps reduce the amount of code needed for common schematic use cases. JSON parse errors will also result
in an exception being thrown with a message detailing the error.
The schematics `Tree` now contains an additional `readText` method that supports directly
reading the content of a file as UTF-8 text. This avoids the need to manually decode a Buffer
within a schematic when text content is needed. If a file path does not exist, an exception
will be thrown. While this differs from the semantics of `read`, it helps reduce the amount
of code needed for common schematic use cases.
An experimental browser application builder (`browser-esbuild`) has been introduced that leverages esbuild as the bundler.
This new builder is compatible with options of the current browser application builder (`browser`) and can be enabled
for experimentation purposes by replacing the `builder` field of `@angular-devkit/build-angular:browser` from an existing
project to `@angular-devkit/build-angular:browser-esbuild`. The builder will generate an ESM-based application and
provides support for ES2015+ compatible output with ES2020 as the default.
This builder is considered experimental and is not recommended for production applications.
Currently not all `browser` builder options and capabilities are supported with this experimental builder.
Additional support for these options may be added in the future.
The following options and capabilities are not currently supported:
* Stylesheet Preprocessors (only CSS styles are supported)
* Angular JIT mode (only AOT is supported)
* Localization [`localize`]
* Watch and dev-server modes [`watch`, `poll`, etc.]
* File replacements [`fileReplacements`]
* License text extraction [`extractLicenses`]
* Bundle budgets [`budgets`]
* Global scripts [`scripts`]
* Build stats JSON output [`statsJson`]
* Deploy URL [`deployURL`]
* CommonJS module warnings (no warnings will be generated for CommonJS package usage)
* Web Workers
* Service workers [`serviceWorker`, `ngswConfigPath`]
The string helpers are predominantly used within schematics that will already depend and import from
the `@angular-devkit/schematics` package. By re-exporting from `@angular-devkit/schematics`, the need
to directly depend and import `@angular-devkit/core` within a schematic can be reduced and in many
cases eliminated.
The `glob`-based check when adding the sourcemap support packages to the karma setup was incorrectly
skipping the files due to Windows pathing issues. The `glob`-based check, however, is unneeded due
to the already present `require.resolve` checks for the sourcemap support packages which will
throw if the packages are not present.
This is not needed as inputs are typed checked to be `JsonValue`. With this change we get a step closer to remove `fast-json-stable-stringify` dependency.
The `_resolveReferenceString` abstract method of the `FileSystemEngineHostBase` class now has a third parameter
that provides the collection description of the schematic currently being resolved. This allows the resolver to
use any fields/options present within the collection description to adjust the resolution of the schematic. The
`encapsulation` optional field is also added to the `FileSystemCollectionDescription` type which will in the future
allow control of the `@angular/cli` VM context wrapping on an individual schematic collection basis.
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 `normalize` 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.
Without the `node_modules` prefix, projects named the same as the excluded package names ex: `webpack` will not compile successfully as all files under the mentioned project will be excluded from being requested by the respective loaders.
Closes#22902
With this change we deprecate exception classes that are not used in the CLI repo.
DEPRECATED:
- `ContentHasMutatedException`, `InvalidUpdateRecordException`, `UnimplementedException` and `MergeConflictException` symbol from `@angular-devkit/core` have been deprecated in favor of the symbol from `@angular-devkit/schematics`.
- `UnsupportedPlatformException` - A custom error exception should be created instead.
These changes include fixes to tests, timeout and stop of architect to make tests work with Jasmine 4.
One noticeable change that when we didn't stop architect through `run.stop()` this causes Bazel to timeout now.
Example
```
-- Test timed out at 2022-03-24 12:07:07 UTC --
/private/var/tmp/_bazel_alanagius/5168427e57f204ca069c602aa7ed1931/sandbox/darwin-sandbox/398/execroot/angular_cli/bazel-out/darwin-fastbuild/bin/packages/angular_devkit/build_angular/build_angular_browser_test.sh.runfiles/angular_cli/packages/angular_devkit/build_angular/build_angular_browser_test.sh: line 424: 41835 Terminated: 15 "${node}" ${LAUNCHER_NODE_OPTIONS[@]+"${LAUNCHER_NODE_OPTIONS[@]}"} ${USER_NODE_OPTIONS[@]+"${USER_NODE_OPTIONS[@]}"} "${MAIN}" ${ARGS[@]+"${ARGS[@]}"} 0<&0
```
With this change we replace the custom dimension 8 `AOT Enabled`, with `Angular CLI Major Version`. The motivation behind replacing this dimension is that the there is already an `aot` dimension with id 13 which serves for the same purpose.
More information to why we need a new dimension for the Angular CLI major version can be found #22130Closes#22130
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.
