Currently, the IndexHtmlWebpackPlugin generates the index.html file *during* bundling. However, to support differential loading the builder must do this *after* bundling because only then we know the produced files for ES5, ES2015, etc.
Hence, this extracts the IndexHtmlWebpackPlugin logic to a helper function which can still be called by IndexHtmlWebpackPlugin for use cases not affected by differential loading (e. g. ng serve) as well as directly by the builder.
https://docs.google.com/document/d/13k84oGwrEjwPyAiAjUgaaM7YHJrzYXz7Cbt6CwRp9N4/edit?ts=5c652052
1. Remove imports of es6 polyfills introduced by the CLI.
2. Refactor the migrations for version 8 by moving the codelyzer and
polyfill transforms into different files.
The PR drops all `core-js/es6` polyfills that we've introduced with the
CLI, except the commented ones. We do not remove commented imports,
since they are not part of the internal es6 polyfills.
The migration automatically drops the
associated comments with the removed imports since they are part of the node - under its
`jsDoc` property.
If a custom path is provided the webpack dev server client drops the sockjs-node segment. This adds it back so that behavior is consistent when using a custom URL path.
Fixes#13627
This feature ONLY matches the format below:
```
loadChildren: () => import('IMPORT_STRING').then(m => m.EXPORT_NAME)
```
It will not match nor alter variations, for instance:
- not using arrow functions
- not using `m` as the module argument
- using `await` instead of `then`
- using a default export (https://github.com/angular/angular/issues/11402)
The only parts that can change are the ones in caps: IMPORT_STRING and EXPORT_NAME.
With this change the builder will report the emitted chunks and assets after the compilation, this is needed for deferential loading so that we can build an index from the outputs of multiple builds
BREAKING CHANGE: we no longer use `node-sass` by default, instead we use `sass` (dart-sass).
While in most cases this should not have an impact the generated code, dart sass has some differences from Ruby Sass. See https://github.com/sass/dart-sass#behavioral-differences-from-ruby-sass for more details
If you wish to use `node-sass` instead of `sass` you need to install node-sass as a dev dependency.
npm users
```
npm install node-sass --save-dev
```
yarn users
```
yarn add node-sass --dev
```
**Note:** for larger Sass projects to avoid this performance hit you might want to install `fibers`. See: https://www.npmjs.com/package/fibers
Ref: TOOL-748
Schematics context now have an (optional) analytics field that, if set,
should be used to report usage. This can be set even in some cases where
analytics is disabled (to a noop analytics).
