I guess this is the righ…

I guess this is the right place, the building of only the affected parts of the app seems really cool, but what i dont understand is if that relies on some kind of persistent artifacts in ci. If it’s only rebuilding what changed, the resulting build would not work if deployed, right?

Responses:

TL;DR; nx affected does not rely on persistent artifacts in CI. nx-cloud and the local computation cache provide you with persistent artifacts to help speed up in a complementary way.

There are two related concepts: nx affected and the computation cache.

Let’s use the example diagram below.

If lib1 is changed, nx affected:build will build both App1 and App2. App2’s build script will compile lib1 , lib2 and app2 code into a build artifact. In this scenario, affected didn’t actually save you any time. nx affected:test would save time by not running the unit tests for lib2.

With caching turned on (and lib2 set up as a publishable/buildable library), nx affected:build would still build both app1 and app2, but when building the lib2 portion, it would use the cached artifact instead of redoing the work.

More information on affected: https://nx.dev/angular/guides/ci/monorepo-affected

More information on buildable libraries/incremental builds: https://nx.dev/angular/guides/ci/incremental-builds