* refactor(@ngtools/webpack): support import-based loader resolution
* fix(@angular-devkit/build-angular): ensure correct ngtools loader version
By using the the direct import approach, the loader will be guaranteed to originate from the same package version/location as the other `@ngtools/webpack` imports.
Fixes#13539
At the moment, if a user provides multiple tsconfig, a file needs to be part of all compilations as otherwise it will fail.
This PR changes this behavour and as long as it's in one of the compilations it will not error out.
Fixes#13399
The warning points to a solution for the WDS disconnect issue. Using --disable-host-check
will additionally warn the user that this might be insecure.
Fixes#11060
This reverts commit edb84b340ff996df2ca6a2aaf765304cc64fef3e
The team has decided to bring back the faster but potentially less accurate method of detecting lazy routes upon JIT rebuilds (first builds will always use the more complete Angular compiler method). Applications that do not have lazy routes within libraries and that only use direct string literals with loadChildren should not be affected by the potential of less accurate detection. Note that the function overload of loadChildren also does not apply to this situation.
For those projects where correctness of lazy route detection outweighs rebuild speed, please consider using AOT mode for development. AOT mode will also provide a full set of template errors as well which JIT mode is not capable of doing.
Fixes#13102
This also adds the option to provide addition files when using `createTypescriptContext` this is paramount for the elide imports tests as without this certain symbols won't have the full details.
Which will cause tests to be false positive and re-surface issues like #13212
When using the `specifier.propertyName` with `typeChecker.getSymbolAtLocation` it will return a more detailed symbol then we originally have in the `usedSymbols` set.
We should probably use `symbol.id` to actually check if the symbols are the same, however the `id` is not exposed in the Symbol interface.
Using `node.name` will return the same symbol that we have stored in the set.
Fixes#13212
