NX runs unnecessary tasks when building app while using buildLibsFromSource=true

[mirobo]

Current Behavior

When I'm running a production build of an app with buildLibsFromSource: true, NX will still run all other "build" targets from the buildable libraries because of the target defaults. But if I understand correctly they wouldn't need to be built at all because the app and the libs are built from the source anyway.

According to https://nx.dev/nx-api/angular/executors/dev-server#buildlibsfromsource the default is buildLibsFromSource=true but also having "build" depend on "^build" is the default in nx.json. I guess changing this could improve build times for a lot of people, wouldn't it? In the end each buildable library used @nx/angular:ng-packagr-lite which produces something which is not used by default..

So finally, I removed "dependsOn": ["^build"], in the targetDefaults just to see.. and it still works..

Did I miss something fundamental here?

Edit:
In real life I have 170+ buildable libraries. I thought I'd profit from the incremental build by later setting buildLibsFromSource: false but NX will (or needs to) check if every library is updated (even checking the cache will be slow with so many projects). We have a lot of separate libraries to get more out of NX affected (i.e. by only running affected Cypress component tests).

Expected Behavior

When buildLibsFromSource is true (which it is by default) a prod build shouldn't execute all other depending libraries "build"-target. Or add a hint in the documentation on how it is supposed to work and how to work around it (in a supported manner).

GitHub Repo

https://github.com/mirobo/nx-angular-tailwind

Steps to Reproduce

• git clone https://github.com/mirobo/nx-angular-tailwind.git
• npm i
• npx nx run demo:build:production

Nx Report

Node   : 18.14.0
   OS     : win32-x64
   npm    : 9.3.1
   
   nx                 : 17.2.8
   @nx/js             : 17.2.8
   @nx/jest           : 17.2.8
   @nx/linter         : 17.2.8
   @nx/eslint         : 17.2.8
   @nx/workspace      : 17.2.8
   @nx/angular        : 17.2.8
   @nx/cypress        : 17.2.8
   @nx/devkit         : 17.2.8
   @nx/eslint-plugin  : 17.2.8
   @nrwl/tao          : 17.2.8
   @nx/web            : 17.2.8
   @nx/webpack        : 17.2.8
   typescript         : 5.2.2

Failure Logs

No response

Package Manager Version

No response

Operating System

• macOS
• Linux
• Windows
• Other (Please specify)

Additional Information

No response

[AgentEnder]

If buildLibsFromSource is true, you can override the build targets dependencies by specifying dependsOn: [] in project.json. The default build: { dependsOn: ["^build"]} indeed doesn't make sense for all workspaces, specifically in cases where using a bundler that doesn't reference prebuilt files.

Perhaps the generated angular configuration should overwrite the dependsOn config from nx.json in project.json.

[mirobo]

Thank you very much for your response! I'm not quite sure what kind of projects rely on build-dependencies being run when the default is buildLibsFromSource=true. It would come in handy if you would know how many people use the flag (and how) :D

I guess one could have a UI library which creates some files (properly referenced in "outputs") which are then required by the app (generating/downloading graphics, icons?)... but then again, the project isn't really "built from the source" but currently it would work.

Maybe it's best to update the documentation or to build in some warnings or suggestions on how NX users could potentially improve their build speed? Or announce to think about removing to flag altogether to see how many users will speak up ;-)
Or as you suggested: Override dependsOn config in project.js (or do it internally if buildLibsFromSource is true?)

[Coly010]

I agree that this sometimes does not make sense 🙂

There is however an issue with further dependencies.

Let's say I have an app myapp and 2 libraries mylib and my-buildable-lib.

myapp -> mylib
mylib -> dist/my-buildable-lib

Such that myapp builds from source for mylib but mylib needs the build output from my-buildable-lib.
Then we still need to build some dependents, so not building them by default could cause issues.

Perhaps users should be expected to know this and set up their dependsOn themselves, however, I think it more likely that if a user specifically chooses to create a buildable library and consume it in their application, then they are trying to use the built output from the library and therefore having a default of building dependencies makes sense.

I've converted the issue to a discussion though so it can be discussed further

[mirobo]

I only have a sample size of 2 projects, but in both projects it was not an issue when "dependsOn: []". But I can't predict how other projects would handle this

But I've found another issue (for existing projects) 😁:

Currently libraries can have different Angular configurations (in my case "strictTemplates"). If I would build only the main app as a whole then all libraries would need to satisfy the Angular configuration of the app. When building each library, you have the option to use (and also verify!) strictTemplates on a per-library basis. In a huge code base, this is handy, so you can introduce strictTemplates step by step (don't ask me why it wasn't activated from the beginning ;-)). And then the app configuration just has strictTemplates turned off, so it won't fail locally when the app is built from source (and some libs are not strictTemplate-ready).

I think a hint in the documentation might be enough after all :-)