Fix: handle `--trackDeps` dependencies without version

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”.

[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.

[yjaaidi]

Thanks @klern, the initial implementation of trackDeps was just meant to propagate versioned dependencies to parents’ changelogs. As discussed here too https://github.com/jscutlery/semver/issues/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.