Fix: handle --trackDeps dependencies without version

[edbzn]

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

[airtonix]

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

[edbzn]

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

[gabsmprocha]

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

[yjaaidi]

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?

[JasonPingAesop]

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.

Thanks @yjaaidi, I do face the first issue as you mentioned in your first questions. If A has dependency on B and written in dependencies or peerDependencies, once we update B's version, we need that new version reflected in A package.json too, otherwise it will keep using the old version of B.
I believe the track flow should be from bottom to top. Once B has version update, it need find all the parents which have dependency on it based on dependency graph and update both their own version (as patch) and the B's version in dependency field (in package.json). Not sure whether need create another option to enable this.

[rkclark]

+1 for behaviour Y! 🙏 Thanks for the great library.

[paulo9mv]

Y. feature libs (unversioned) should affect parent changelog... transitively (e.g. App => Domain Feature Lib => Domain Data-Access Lib)

This would be ideal to make semver use perfect 🙏
Since we are using mental-model with 80% code on libs, most of commits are changes only on libs. But this changes affects apps and versioning is only on apps in our scenario.