Open g-cheishvili opened 10 months ago
This seems quite an edge case, as build
architect target is actually what is executed during ng build
. Without this ng build
would fail.
What is the use-case of not having a build
target?
For example, I myself have a project, based on nx, which has application build target called "compile" and sub-libraries have "build", this is for removing the link between the app and lib builds. As a result application builds way faster because It does not depend on other build targets, it can be built without invoking the dependency builds. This is one case that I'm having for example, others might have other reasons to not call their builder targets explicitly "build" and when in such applications someone installs a 3rd party library, with ng-add
the main files can not be found, precisely because of the getMainFilePath
utility function. If that utility function is able to gather more information from the user, regarding their unique alignment of the workspace, then it will be beneficial for the end-user
This seems quite an edge case, as
build
architect target is actually what is executed duringng build
. Without thisng build
would fail.What is the use-case of not having a
build
target?
ng build
might fail, but Angular workspace is not the only one in the community which orchestrates Angular applications. You could also run ng run app:compile
so it would be no different, would it ?
It is true, that you can ng run app:compile
, and whilst build
target is not strictly required. It's there is there in the majority of cases.
That said, we should probably handle this case a bit better but this is also not limited to the getMainFilePath
. As there are other schematics were build
is expected to exist.
Quick search resulted in:
In this case, probably if build
does not exists we should probably try to locate the know builders by name instead.
The problem with the finding "build" target with a builder instead of allowing user to select it, is that there are numerous other builders, besides provided by the Angular. For example Nx has it's own custom builders, built on top of the Angular's ones. Same goes for the @angular-builders
for example. The point it that there are other builders, besides Angular's ones and there are two problems, one being that Angular always explicitly looks for the build
targets and even if does not look for that name, then it looks for the builder names, which are not exclusively coming from the Angular.
Perhaps, the best way would be to locate using known builders and if there are none found, then we ask to the user what the hell is going on in their workspace?
The PR that I provided is the same code that I'm using in my new ng-add
schematic that I'm working on, just I thought that if the feature would come from the Angular itself, I would not have to check whether Builders
had changed over the span of different versions
Command
add
Description
I've seen a lot of cases when people are using different name for their build targets, for various reasons. So if the
build
is not found, thegetMainFilePath
fails, which is not right in my opinionDescribe the solution you'd like
It should ask interactively which target should be used if
build
is not found, when interactivity is enabled in the execution contextDescribe alternatives you've considered
No response