2.x->3.x - lerna version - EUNCOMMIT Working tree has uncommitted changes

[rosskevin]

Expected Behavior

lerna version should allow updating package versions regardless of commit status when git is effectively ignored (--no-git-tag-version --no-push).

Current Behavior

--skip-git is no longer relevant in 3.x, so verification may be occurring when we previously were allowed to avoid it. When there are uncommitted changes and lerna version patch --yes --no-git-tag-version --no-push is run, the result is a lerna ERR! EUNCOMMIT Working tree has uncommitted changes

Possible Solution

If it is too far to assume that --no-git-tag-version --no-push means avoid clean workspace verification, perhaps an override --no-git-clean-check or something of the same intent?

Steps to Reproduce (for bugs)

1. Use any lerna repo
2. Make a change
3. Run lerna version patch --yes --no-git-tag-version --no-push

lerna.json

{
  "lerna": "2.9.0",
  "version": "1.2.0",
  "npmClient": "yarn",
  "useWorkspaces": true
}

Context

We encountered this when updating from 2.x to 3.x based on the recommended CLI messages. Previously, we were using the lerna publish command to simply update the versions.

We use a git-flow workflow and rely on lerna for exec, versioning and updated functionality.

In 3.x this command with deprecated options works but we want to fix our deprecated usage:

lerna publish --yes --cd-version patch --skip-npm --skip-git
WARN deprecated --cd-version has been replaced by positional [bump]
WARN deprecated --skip-git has been replaced by --no-git-tag-version --no-push
lerna notice cli v3.1.4
lerna WARN deprecated Instead of --skip-npm, call `lerna version` directly
lerna info current version 1.1.0
lerna info Looking for changed packages since initial commit.

Changes:
 - foo: 1.0.1 => 1.1.1
 - bar: 1.0.0 => 1.1.1 (private)
 - baz: 1.0.0 => 1.1.1 (private)

lerna info auto-confirmed
lerna info execute Skipping git tag/commit
lerna info execute Skipping git push

Given this, we were excited about the new lerna version as it better fits into our git-flow workflow, but we encountered the uncommitted message - which I agree is a good thing, except when we might want to override it.

lerna version patch --yes --no-git-tag-version --no-push
lerna notice cli v3.1.4
lerna info current version 1.2.0
lerna info Looking for changed packages since v1.2.0
lerna ERR! EUNCOMMIT Working tree has uncommitted changes, please commit or remove changes before continuing.

Your Environment

Executable	Version
lerna --version	3.1.4

[rosskevin]

It looks like adding --amend will opt out of the dirtiness check, though seems like a misuse, or perhaps the option could be renamed, I am not sure which makes the most sense in the entire scope of lerna.

https://github.com/lerna/lerna/blob/master/commands/version/index.js#L157

[evocateur]

Yeah, you don't want to pass --amend for that purpose. I now regret accepting the option in the first place.

To clarify, git is not "effectively ignored" when passing this option, it's just avoiding git commit and git tag; there are several other git commands that are always run regardless of --no-git-tag-version. I'm not sure why git-flow necessitates running lerna half-cocked.

In any case, when an existing pattern from npm exists (such as npm version), I try to match its behavior. Turns out --no-git-tag-version allows npm version to proceed on a dirty tree, and omitting it does not. So I'm fine with allowing --no-git-tag-version to skip dirty tree validation.

[submjn]

While using lerna 2.11.0, to publish I used "lerna publish --skip-git --cd-version patch --yes",
It was working fine, but It was causing infinite build on circleCI. I upgraded lerna to 3.x and now I used all these above mentioned commands, I am getting same issue

lerna publish from-git --npm-client npm

lerna notice cli v3.3.0
lerna ERR! EUNCOMMIT Working tree has uncommitted changes, please commit or remove changes before continuing.

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