Optionally make affected algorithm more precise

[vigie]

Apologies if this is being discussed elsewhere, I did look....

Currently projA is affected by projB if projA imports anything from projB.

This is as conservative and fool proof as possible. It also however often results in too much building/testing when projB for example contains a set of pure utility functions.

I have read the discussions where the answer at this point is to "refactor projB". I don't want to go down that route here. Let's assume we wish to let developers decide how to best organize their code as far as possible.

The proposal is to allow affected to actually analyze what is being imported from projB before declaring that it has been affected by a change to projB.

In order to do this safely, affected would have to assume projB is a pure project, that is, the exporting and usage of items from projB does not trigger side effects. For example, there is no arbitrary code in projB's index.ts file doing weird stuff in global space.

In general (unfortunately), this is not a safe assumption to make. So the proposal is to provide a mechanism to allow users to declare certain libraries as "pure", in order to benefit from the optimized algorithm.

This could be done as simply as adding a new pure property to projects in nx.json, for example.

[laurentsd]

hi Matt, this is an interesting proposal. Can you provide an example of such projB that seems difficult or not worth refactoring in your case? Some may argue that the question becomes how granular your projB library is, and how optimized your CICD is if it’s very costly for every change. How would the pure flag work in practice?

[vigie]

Sure, let's give projB the name widgets. It sits as a leaf of my project tree and gathers generic, widely applicable but non-essential components that do not (yet) have a more obvious home. Application projects within the monorepo each consume some subset of the components exposed by widgets and that subset may change over time.

The nx affected algorithm is altered as follows: for any project marked as pure, gather the set of objects imported by a dependent project. The dependent project is affected by the changed project if and only if one of those objects was changed. The changed status of the object is determined by looking for either direct changes to its definition or changes to its dependencies, which are all assumed to be pure within the same project but could cross the border to other projects which may or may not be pure.

[vigie]

I understand that calculating change at the object level may well be too difficult/expensive, but even if just done at the module level I think we'd get 90% of the benefit, considering that objects exported from the same module are typically closely related.

So, the simplification here is: consider a project affected by a change in another if that project imports anything from a module that was changed (directly or transitively).