Fix: handle `--trackDeps` dependencies without version

[Edouard Bozon]

Using --trackDeps with non-versioned dependencies will produce incorrect entries in the changelog.

App A versioned, depends on:

• lib B (not versioned)
• lib C (not versioned)

Will produce:

### Dependency Updates

* lib B updated to version `0.1.0`
* lib C updated to version `0.1.0`

Even if lib B & C are not versioned, the changelog displays "updated to version 0.1.0" which is incorrect, the message should only be "lib B updated".

[Zeno Jiricek]

Even if lib B & C are not versioned, the changelog displays "updated to version 0.1.0" which is incorrect, the message should only be "lib B updated".

you mean it should be :

### Dependency Updates

* lib B updated
* lib C updated

[Edouard Bozon]

@airtonix yes!

[klern]

Is it possible to write all commit messages in those updated libs into the changelog?
I followed NX Mental model rule, placed 80% logic into libs. But changelog does not display those updates.

[Gabriela Rocha]

it would be interesting to add the option to generate the commits of the affected libs in the app they belong to

Think of a scenario of a monorepo with many applications and libs, and the flow of versioning and publishing releases happens after a PR is merged via github actions, even if the libs themselves have their changelogs, they would all have to be committed, libs tend growing faster than apps, not to mention that with this approach the commit would only be in the app

[Younes Jaaidi]

Thanks @klern, the initial implementation of trackDeps was just meant to propagate versioned dependencies to parents' changelogs.
As discussed here too #566 with @gabsmprocha, we probably have to rethink the way trackDeps work.

There are a couple of questions that we should ask ourselves first:

1. if a dependency (B) is versioned, does it make sense to bump the parent (A)?
   In most cases, if the dependency is versioned, then it is probably an NPM package or a publishable library of any sort.
   This means that what would bump the parent is when we change its package.json to update the dependencies or peerDependencies with "B": "^2.0.0" and that commit will tell if it's a breaking change or not.
   A breaking change on a dependency isn't automatically a breaking change on the parent.

2. if a dependency (B) is not versioned, then can we assume that its changes are embedded in the parent (A)?
   In this case, B is probably a "feature" of A so any change on B is a change on A. We have to analyze B commits and put them in A's changelog while bumping it.

3. On the other hand, we can have multiple apps using a UI library that is versioned but not published so apps are automatically using the current UI version. What should we do in this case?
   Should we patch bump? or sync bump just like in B?
   In both cases, we would put a link to B's changelog instead of all the commits in the changelog.

TL;DR: default behavior of trackDeps should satisfy the 3 following use cases:
X. publishable dependencies should not be tracked as the bump is related to parent's package.json's dependencies & peerDependencies...
Y. feature libs (unversioned) should affect parent changelog... transitively (e.g. App => Domain Feature Lib => Domain Data-Access Lib)
Z. versioned but unpublishable libs should affect parents just like Y and add a link to lib's changelog
By the way, Z is the current behavior of --trackDeps.

[klern]

Thanks! My use case is the same as the second question you mentioned, the behavior Y is a great solution for me.

About the third question, I'm curious that if someone updated UI library, but release the apps which use the UI library before updating the version of UI library (bad workflow, but may happen 😅 ), what behavior should happen in this scenario? Will it list the current version of UI library and new commit messages of UI library in the apps' changelogs?