A custom builder can call `context.scheduleBuilder` to call another builder.
However, the following call will fail with `Must either have a target from
the context or a default project.` exception because `scheduleBuilder` does
not pass `target` to the called builder.
```typescript
import { JsonObject } from '@angular-devkit/core'
import { BuilderContext, BuilderOutput, BuilderRun, createBuilder } from '@angular-devkit/architect';
import { Observable, from } from 'rxjs';
import { concatMap, map } from 'rxjs/operators';
export default createBuilder(_customBuilder);
function _customBuilder(options: JsonObject, context: BuilderContext): Observable<BuilderOutput> {
const builder = '@angular-devkit/build-angular:browser';
return from(context.scheduleBuilder(builder, options)).pipe(
concatMap(run => run.result)
);
}
```
Resolves:
https://github.com/angular/angular-cli/issues/15053
By using the `SchemaValidationException` object, the underlying JSON schema validation errors will be propagated to the consuming code. This allows for more detailed error reporting of malformed or incorrectly provided options.
Partially addresses #14269
getBuilderNameForTarget() allows someone to get the builder name string for a specific
target (or return a rejected promise if it fails).
validateOptions() allows a builder to validate options against the same mechanics that
are used when scheduling builders.
These two methods allow builders to get options from a workspace (or build some option
object), change it, validate it, and execute scheduleBuilder() if they want to schedule
directly (or want a parallel run).
It came up with Nrwl that this is a common pattern; someone wants to schedule a
target but does not want to manage the run himself. This function cancels the
run when the Observable is unsubscribed from (which is not the case for a
traditional run).
Because stop logic can be asynchronous, we need to add a teardown logic
handler to the context, which turns out to be useful for other cases as
well.
Add a scheduling options to scheduleTarget and Builder on the context so
builders can schedule sub-builds and override the logger.
Add a getTargetOptions() for builders to get access to options from the
host for a specific target. This allows builders to get options, override
some, then scheduleBuilder with those new options, for example.
If an error is reported but ANY subscription have an undefined error handler, RxJS
reports the error to the "host platform" (it setTimeout(() => throw error)). Since
we properly handle errors in some places, but should ignore them in others (e.g.
we handle errors on the outboundBus, so the output subscription should ignore it),
we still need to subscribe to error, just ignore it.
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.
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.
