```
DEPRECATION: An asynchronous before/it/after function was defined with the async keyword but also took a done callback. This is not supported and will stop working in the future. Either remove the done callback (recommended) or remove the async keyword.
```
This previously caused an `UnhandledPromiseRejection` which caused tests not to run. But Jasmine, still reported success.
```
yarn bazel test //packages/angular_devkit/core:core_test --test_summary=detailed --test_output=all
INFO: Analyzed target //packages/angular_devkit/core:core_test (1 packages loaded, 10 targets configured).
INFO: Found 1 test target...
Target //packages/angular_devkit/core:core_test up-to-date:
dist/bin/packages/angular_devkit/core/core_test.sh
dist/bin/packages/angular_devkit/core/core_test_loader.js
dist/bin/packages/angular_devkit/core/core_test_require_patch.js
INFO: Elapsed time: 0.327s, Critical Path: 0.03s
INFO: 1 process: 1 internal.
INFO: Build completed successfully, 1 total action
PASSED: //packages/angular_devkit/core:core_test (see /private/var/tmp/_bazel_alanagius/5168427e57f204ca069c602aa7ed1931/execroot/angular_cli/bazel-out/darwin-fastbuild/testlogs/packages/angular_devkit/core/core_test/test.log)
INFO: From Testing //packages/angular_devkit/core:core_test
==================== Test output for //packages/angular_devkit/core:core_test:
(node:12829) UnhandledPromiseRejectionWarning: Error: Cannot find module '/private/var/tmp/_bazel_alanagius/5168427e57f204ca069c602aa7ed1931/execroot/angular_cli/node_modules/@angular-devkit/core/src/index.js'. Please verify that the package.json has a valid "main" entry
at tryPackage (internal/modules/cjs/loader.js:303:19)
at Function.Module._findPath (internal/modules/cjs/loader.js:516:18)
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:867:27)
at Function.Module._load (internal/modules/cjs/loader.js:725:27)
at Module.require (internal/modules/cjs/loader.js:952:19)
at require (internal/modules/cjs/helpers.js:88:18)
at Object.<anonymous> (packages/angular_devkit/core/src/virtual-fs/host/memory_spec.ts:10:1)
at Module._compile (internal/modules/cjs/loader.js:1063:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1092:10)
at Module.load (internal/modules/cjs/loader.js:928:32)
at Function.Module._load (internal/modules/cjs/loader.js:769:14)
at Module.require (internal/modules/cjs/loader.js:952:19)
at require (internal/modules/cjs/helpers.js:88:18)
at Loader.requireShim [as require_] (node_modules/jasmine/lib/loader.js:35:3)
at node_modules/jasmine/lib/loader.js:28:12
at new Promise (<anonymous>)
at Loader.load (node_modules/jasmine/lib/loader.js:27:12)
at Jasmine.loadSpecs (node_modules/jasmine/lib/jasmine.js:91:23)
at Jasmine.execute (node_modules/jasmine/lib/jasmine.js:267:3)
(Use `node --trace-warnings ...` to show where the warning was created)
(node:12829) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
(node:12829) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
================================================================================
Test cases: finished with 1 passing and 0 failing out of 1 test cases
Executed 0 out of 1 test: 1 test passes.
```
With this change we provide earlier feedback in the console during a build. The setup phase can take some times if the project has a large set of dependencies.
We also move several warnings in the dev-server to an earlier phase so that we don't clutter the progress indicator.
Closes#20957
The process has changed and post-release bumps are no longer necessary.
Also updated the doc to include a section on changing shifts with the caveat that you must be logged in to the `@angular.io` account to have edit access to the calendar.
When executing the add-pwa E2E test with Angular snapshots, the package versions need to be updated after the `ng add @angular/pwa` call to ensure that the correct version of `@angular/service-worker` is used.
Yarn requires a different package installation strategy due to Yarn not always installing a new version of a github sha when directly adding an individual package.
The new `ngtools/webpack` option leverages the inline resource matching syntax combined with a custom loader instead of data URIs. This provides better resource path in loaders that do not yet fully support scheme-based resource requests.
Webpack provides a method to construct a special request string that will remap a loader chain to appear to be from a specific resource path. This requires a custom loader, however, it allows rule matching to leverage the existing file extension based approach and allows providing a path to other loaders which simplifies relative request handling.
When executing the add-pwa E2E test with Angular snapshots, the package versions need to be updated after the `ng add @angular/pwa` call to ensure that the correct version of `@angular/service-worker` is used.
Loading the postcss-preset-env plugin includes building a mapping of unsupported
browsers by feature, which is somewhat expensive. In large compilations, this mapping
would be recomputed for each postcss-loader instance, as the plugin was recreated
for each loader invocation. By extracting the plugin instance outside of the dynamic
plugin computation, this overhead is avoided.
Since #20518, the generation of the ServiceWorker configuration has been
broken on Windows. The reason is the use of `path.posix.*` methods on
non-POSIX paths, resulting in broken paths. I.e. we ended up with
something like the following:
```js
path.posix.relative('C:\\foo', 'C:\\foo\\bar/baz');
// Expected result: `bar/baz`
// Actual result: `../C:\\foo\\bar/baz`
```
This caused the config generator to fail to find any files and thus fail
to populate the config with cacheable assets.
This commit fixes this by using platform-specific `path.*` methods for
path manipulation and manually normalizing the path separators before
returning the results.
Fixes#20894
Unsupported versions of Node.js will now show an unsupported warning when the `ng version` command is executed.
Currently Node.js major versions 12 and 14 are considered supported and tested.
Closes#20879
With this change we re-emit assets referenced in component stylesheets which where uneffected by the change that re-triggered a re-compilation.
Since we cache the the result of processed component CSS, during a re-compilation `postcss-cli-resources` plugin will not run which causes assets to be to emit. With this change we now cache the asset and re-emit them on every change.
Closes#20882
Since we rely on child compilations to compile components CSS, using the `parallel` option will cause a significant overhead because each compilation will need to spawn a worker, in this mode the worker limit is not be honored because `css-minimizer-webpack-plugin` spawn and calulators workers during the optimization phase of a compilation and not globally per instance hence causes OOM because a large number of workers to be spawned simultaneously.
Closes#20883
As reported in #20113, webpack triggers a Trusted Types violation when
lazy-loading is used. To mitigate that, enable webpack's Trusted Types
module (introduced in webpack/webpack#9856) using 'angular#bundler' as
the policy name.
Ensure that a simple Angular application is compatible with Trusted
Types, even when lazy-loading is used. This test currently fails due to
a Trusted Types violation originating in Webpack.
The Worker constructor option for a transfer list is unfortunately not supported until Node.js 12.17. For Node.js versions prior to 12.17, a manual message post is now used to transfer the necessary initialization data to the Sass workers.
When not in a watch mode, the analyis performed by TypeScript to improve incremental type checking can be avoided by creating an abstract builder program that only wraps the underlying TypeScript program.
Performance enhancements in the upcoming TypeScript 4.3 may remove the need for this. However, TypeScript 4.3 is not yet released and is not yet supported. In addition, TypeScript 4.2 will continue to be supported throughout the v12 major even when TypeScript 4.3 is also supported.
AJV only support a single schema with the same ID, compiling schemas async can cause a race condition were multiple schemas with the same name as compiled at the same time.
Closes#20847
This reduce memory consumption during re-builds.
```
runtime.ba93f81591909b93394f.hot-update.js.map will be removed
styles.ba93f81591909b93394f.hot-update.js.map will be removed
runtime.ba93f81591909b93394f.hot-update.json will be removed
runtime.ba93f81591909b93394f.hot-update.js will be removed
styles.ba93f81591909b93394f.hot-update.js will be removed
```
See https://github.com/webpack/webpack/issues/12947#issuecomment-812108140 and https://github.com/webpack/webpack/issues/13127
