At the moment users can have various casing and seperatirs in paths, we should not always dasherize the name when resolving modules.
As for example when providing something like:
```
/module/SubModule/feature
```
It won't be able to resolve the modules properly as `sub-module` does't exist.
This PR also updates the test for underscore as previously it was not properly testing this usercase, since the formatter was used on name and not th path.
Fixes#13714
Angular 5.0+ has a full peer dependencies setup (with 6.0+ also having a configurable runtime error check) to ensure that an appropriate version of typescript is available for compilation. Angular CLI 8.0+ does not support Angular versions prior to these and therefore the warning is redundant. For the case where the developer wishes to use an unsupported TypeScript version, the developer would need to adjust two similar but differently name settings in two different configuration files.
This is causing major confusion as users are not aware that choosing `sass` will generate files with `scss` extension.
Another reason for this confusion is that in other schematics, `style` accepts either a preprocessor or file extension while in this prompt only a preprocessor is provided.
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.
If a system wants to have logging it should multiplex it itself on a channel.
Also changed the previous Architect commits to remove usage of Logs and move
to a "log" channel.
Move the entire Architect CLI to use the new API, and report progress using
a progress bar for each worker currently executing. Shows log at the end
of the execution.
This is meant to be used as a debugging tool to help people move their builders
to the new API.
Four builders were added;
- true, always succeed
- false, always fails
- concat, runs all targets or builders in succession
- allOf, runs all targets or builders in parallel
The new API has been described in this design doc:
https://docs.google.com/document/d/1SpN_2XEooI9_CPjqspAcNEBjVY874OWPZqOenjuF0qo/view
This first drafts add support for the API (given some deep imports). It is
still in draft mode but is committed to make it available to people to
start testing and moving their own builders.
This API rebuilds (not backward compatible) the Architect API package. To
use it people will need to import "@angular-devkit/architect/src/index2"
to start using it. A reference builder will be added in the next commit.
There are 2 pieces missing from this commit that will be added in the
same PR; 1) the architect-host and CLI to test, and 2) a reference
builder moved from the old API to the new one. These will be part of
the same PR.
Finally, there are missing tests in this package, but everything tested
manually and automatically works so far. Test coverage will be added
before the package is considered finished.
Due to a desire to keep architect, our tests and the scope of this PR
limited and keep the two APIs separated, every clashing files will
have a "2" suffix added to it. Once all builders have been moved and
we are sure everything works, all those files will be moved to their
final destination and the old API will be removed, in one PR.
Current behaviour is to have logs forwarded, but this is flawed because on the
job side the logger is actually re-created. This allows logs to be actually part
of the caller side logging infrastructure.
It was possible to overwrite the metadata of the logger itself (name, path)
when calling "log()". This should not happen. If there is a need to overwrite
the loggers metadata itself one should use "next()" and construct or forward
their own log entry.
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.
