getMainFilePath util function fails because of hardcoded target name

[g-cheishvili]

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, the getMainFilePath fails, which is not right in my opinion

Describe 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 context

Describe alternatives you've considered

No response

[alan-agius4]

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?

[g-cheishvili]

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

[g-cheishvili]

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?

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 ?

[alan-agius4]

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:

• https://github.com/angular/components/blob/187a7b8dd28b349014e79adae5055359f92bdac5/src/cdk/schematics/utils/schematic-options.ts#L57

• angular-cli/packages/schematics/angular/server/index.ts

  Line 71 in adba8be

  const buildTarget = clientProject.targets.get('build');

• https://github.com/angular/angular/blob/c9f8e75b6f7f3dd229c318bbe36a02f7854a01ce/packages/core/schematics/utils/project_tsconfig_paths.ts#L26

In this case, probably if build does not exists we should probably try to locate the know builders by name instead.

[g-cheishvili]

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?

[g-cheishvili]

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