With directTemplateLoading enabled, components
can now use .svg files as templates. For AOT builds,
the Angular compiler host now reads .svg files
directly when reading component templates.
For JIT builds, replaceResources creates a require call
that directly uses raw-loader instead of using the
loader provided by the current webpack configuration.
Closes#10567
Remove the manually maintained schema.d.ts from the browser builder, and use
the Schema JSON file to generate it. This had a lot of repercussions around
the whole build-angular code base and the different interfaces that were
manually kept.
Previously, all loaders either needed to be in the workspace's node modules directory or a node modules directory directly within the build angular package. A package manager can potentially hoist a loader to a node modules location inbetween the two and causing loader resolution to fail. This change causes webpack to check all intermediate node modules directories in addition to the initial two locations.
BREAKING CHANGE:
Root relative URLs are a standardized method to reference a resource path from the root of a host. The previous behavior of the Angular CLI prevented this from occuring and resulted in an inability to reference stylesheet assets in this manner. The initial reason for this behavior is no longer present in the internal implementation of the Angular CLI. Therefore, this now unnecessary and non-standard behavior is being phased out. If an application currently relies on this behavior, a compatibility option `rebaseRootRelativeCssUrls` has been provided for the 8.x release cycle to facilitate transition away from this non-standard and limiting behavior. The recommended method to transition is to use relative paths within the source stylesheet. This allows the build system to process and generate a full URL for the asset.
* 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
