Confusion with lerna updated and package update detection

[runjak]

When working on one branch using lerna in independent mode, it appears to happen that unchanged packages are listed by lerna updated.

Expected Behavior

Only packages that actually have changed should be listed by lerna updated

Current Behavior

It appears that the getLatestTag function, which uses git describe finds one of the tags that are an ancestor commit to the currently checked out commit. But there may be more than one.

Specifically in my situation I have a commit structure like this:

git describe --tags describes the teamshirts.util… tag as being the latest, but the eslint-config… one has a more recent date. This leads lerna into asking us to update our eslint package even though it hasn't changed since.

Possible Solution

1. It is confusing to me how git describe picks the closest or most recent tag - when comparing to the commit that is not picked by git describe using the same command diffSinceIn uses no changes appear to have happened.
2. Topologically the master branch in the commit structure has two tags that are interesting candidates to compare against. Independent of the choice git describe has it looks to me as if lerna would need to consider both paths/tags to asses changes here.

Steps to Reproduce

1. Create two packages independently, and have tags for both of them.
2. Merge them both into master creating separate merge commits.
3. Changes will be compared only against one of the tags, but not against both.
4. The tag compared against appears different depending on the order of merges.

lerna.json

{
  "lerna": "2.5.1",
  "version": "independent",
  "npmClient": "yarn",
  "useWorkspaces": true,
  "packages": [
    "packages/**/*"
  ]
}

Context

• We're trying to build independently versioned packages with multiple programmers. Each programmer desires to update the packages they changed independently. After review/tests/merge into master these packages are automatically deployed.
• It may be especially interesting to note that changes to packages happened at different times and are done by different programmers (but special attention has been paid to synchronize all tags across machines.).

Your Environment

Executable	Version
lerna --version	2.5.1
npm --version	5.6.0
yarn --version	1.3.2
node --version	v9.5.0

OS	Version
macOS High Sierra	10.13.3

[runjak]

Looking around further it sounds like this issue is similar to #1241 in parts.

Also we might have a workaround for our specific situation where we set a tag on each merge/update in master so that comparisons for updates will always run against that tag.

[evocateur]

I would suggest not publishing tagged releases in feature branches. I guess that horse has left the barn already, however. If feature branches necessitate publishing, you could always lerna publish --canary until it gets merged properly into master.

We're trying to build independently versioned packages with multiple programmers. Each programmer desires to update the packages they changed independently.

Sounds like you shouldn't be using lerna, then?

[runjak]

Hey, thanks for the response :)

Indeed the horse has at least partially left the barn.

But if I'm understanding you correctly your suggestion is to not bump tags in the branches that work on them but to bump only on master instead.

The nice thing with tagging on dedicated branches but publishing to a registry only in master is that we can review version changes as well and no additional step for package bumping is necessary where a single person would need to know details about several package changes.

So far we've managed to create a workaround which uses a tag that follows current master.
But it wouldn't be far fetched to consider switching to a workflow where we bump versions in master if the need arises.

Coming from that I'd say we currently have a better understanding of the desired workflows with lerna than before and can work with our setup as is.
If the workflow we imagined doesn't fit into the scope of this project I think we can close this issue.

---

Side note 1:
I've wondered about the workflow we're using before: https://stackoverflow.com/q/47327884/448591
If this is not the intended use or the suggested pattern makes more sense I'd comment it there as well just so that others don't easily make the same mistake we're doing ;)

Side note 2:
We're already using lerna publish --canary on branches that are prefixed with test - it's a good thing.

[doug-wade]

Closing per #1269 (comment); this use case doesn't really fit the scope of this project.

[lock]

This thread has been automatically locked because there has not been any recent activity after it was closed. Please open a new issue for related bugs.