buildTarget is hardcoded and only modifies configuration

[mpsanchis]

Hi Diego,

Today I noticed two details about the buildTarget option, which imho should be modified for (1) improved understanding and (2) flexibility. These are:

1. The option called buildTarget is actually only modifying the build target configuration. In the end, you call the NX devkit to run something like nx run my-module:my-build-target:my-configuration, and this parameter only modifies the third part of this string. I would expect that, being named buildTarget, it modifies the my-build-target part, not the my-configuration part.
2. I see that you have hardcoded the word build in the code. In most of the cases, the build target of projects will be called build, but what if they're not? I am having issues with the nx-devkit right now, because it won't correctly run the target if it depends on other targets. In my case, I have to run something like build-npm-library instead of the standard build, and because this value is hardcoded in this plugin, I can't even modify it by passing it as an option.

I know that changing these is a breaking change, but semantically would make a lot of sense.

Thank you in advance, and congratulations for the great plugin

[mpsanchis]

Update: adding issue of nx-devkit here for visibility
nrwl/nx#19531

It does not delegate the build work if build has a dependsOn another target which actually builds the project.

[dianjuar]

Hi, @mpsanchis.
Thank you for opening this issue and for the detailed information provided.

Regarding the buildTarget parameter, I'm considering removing it entirety in favor of using dependsOn: ["build"] on the deploy target.

buildTarget has been difficult to understand since its creation. It's not intuitive and adds something else to maintain. I plan on introducing this change in v9 (after #516 gets solved).

As a workaround for you, I suggest having the option noBuild in your deploy target options and setting dependsOn: ["build"] in your deploy target. noBuild will not execute the plugin's build and the dependsOn target option will allow you have control on what's needs to be done before deploying/publishing.

I firmly believe that the dependsOn is the right way to approach it. It's declarative and feels like it is the Nx way to approach this.

Let me know your thoughts about this workaround and if it solves your problem.

[mpsanchis]

I firmly believe that the dependsOn is the right way to approach it. It's declarative and feels like it is the Nx way to approach this.

Agreed :) Actually I was playing with the different alternatives, and this is the cleanest one. Plus, it avoids the nasty bug when calling runExecutor that I mentioned..

[dianjuar]

closed by #571

Changes available on version 8.0.0

[dianjuar]

Thank you, @mpsanchis, for opening the issue and telling us your problem.
For input was deterministic to take action and move this project in the right direction.

The changes are available in version 8.0.0.
You can find more information on how to apply the introduced breaking changes in this blog post