By default the application will be served with inline mode enabled. This means that a script will be inserted in your bundle to take care of live reloading.
However at the moment we are already adding these scripts in `_addLiveReload` method.
With this change we always disable this behaviour and only add it when needed via the `_addLiveReload` logic.
Eventually we should try to remove the logic and rely on webpack-dev-server interals.
Fixes#14300
When we first started using Build Optimizer, we saw a lot of the savings were tied to using the Uglify/Terser `pure_getters` option.
This was intimately related with the structure and shape of the Angular codebase. The measurements we did at the time on angular.io showed a significant size reduction, from 1mb to about 600kb. Of these roughly 150kb were tied to using `pure_getters` if I remember correctly.
Meanwhile the Angular codebase has changed significantly and I don't really see these savings anymore, so I don't think it makes sense to keep it on given that it is known to cause problems with some libraries.
Closes#9231, #11439, #12096, #12128.
When using differential loading with targets ES5 and ES2016+, the
browser with ESM support will pick `script[type="module"]` scripts even
without supporting ES2016+ syntax.
We want to warn users in this case.
Before, the build tasks ran in parallel and so the different webpack
instances competed over the same lines on the console.
To fail fast and to prevent to show the same errors twice, the second
build step is not executed if the first one fails.
As running these tasks in sequence causes issues with watch mode, this
PR also disables differential loading when watch mode is requested.
With this change we turn on differential loading for projects that has es2015 as script target and still want to support browsers which that don't support ES2015.
Supported browsers are defined in the browserlist file.
This change wires up the index generation for multiple bundles, we however don't enable differential loading for users just yet. As this will be done in a separate PR to change over specs to conform with the new files
Since when having differential loading we already know which files originated from which build. We shouldn't need to merge and transform this data.
With this change, the index generator accepts a couple of new inputs.
1. `files` - used for Js and CSS files which require nomodule nor module attributes
2. `moduleFiles` - Js files that need to have a `module` attribute
3. `noModuleFiles` - Js files that need to have a `nomodule` attribute
4. `entrypoints` - used to sort the insertion of files in the HTML file
This PR adds differential loading to the browser builder. First, it checks if differential loading is needed. This is the case if the compilation target is ES2015 while the browserslist points to ES5 browsers.
For providing differential loading, it calls the methods for creating the webpack config for each compilation target (e. g. ES5 and ES2015). The needed differences between those configurations are defined using parameters also added by this PR. Then it calls webpack for each of them and merges the results
This feature is currently hidden behind a flag. To activate it, set the differentialLoading flag in browser/index.ts.
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
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.
