Lerna version needs code to be on a branch

[marikaner]

I am trying to run lerna version in a non-git folder. More specifically I am skipping all git related actions by running lerna version --no-git-tag-version --no-push --exact 0.0.1-SNAPSHOT resulting in failure, due to this check.

Expected Behavior

I would expect this to be independent of git in the same way as npm is and just update the package.json versions:
[Only] if run in a git repo, it will also create a version commit and tag.
This way the --no-git-tag-version --no-push arguments would be obsolete in a non-git project.

Current Behavior

This currently fails with ENOGIT.

Possible Solution

Check the branch only in case the git based features are used (allow-branch, git-tag-version, etc.).

Steps to Reproduce (for bugs)

1. Take any working lerna project, run rm -rf **/.git
2. run lerna version <version>
3. failure 😱

Context

I am using lerna to publish to our internal registry from a central build server. Most of the things happening on this server are out of my hands. There the code is checked out, then stripped of any potential "overhead" files (node_modules, .git and files created by the build), and npm installed.
This is when I set the version.

Currently I was able to work around this issue by running lerna exec npm version 0.0.1-SNAPSHOT.

Your Environment

Centrally managed build server 🔒

Executable	Version
lerna --version	3.7.1
npm --version	6.4.1
node --version	10.14.0

OS	Version
some linux server	--

[evocateur]

Yeah, your server needs to stop stripping .git directories.

Just because you're avoiding certain git operations doesn't mean all git calls are skipped. lerna version uses git to determine what changed since the last tagged release, and there's really no getting around that.

[marikaner]

But should lerna care about what changed? This information is not used in the above described scenario. Wouldn't it be cleaner to skip the overhead of evaluating the git files / determining what changed when this information is irrelevant?

[evocateur]

lerna version also needs to know what packages to apply the version to, not just the new version number itself. It doesn't appear that you're actually intending to propagate this version back to the repository, and you want it globally applied, so I'm not sure lerna version is appropriate in any case. Your workaround seems to be doing fine.

[marikaner]

I guess so ;) Just seemed like odd behavior to me.

[marikaner]

Hello @evocateur,

I have to try this again, because it is driving me crazy right now...

First of all my previous workaround lerna exec -- npm version XXX is not sufficient, because of course our packages are interdependent and the dependency versions need to be updated, too. That is one of the main reasons we are using lerna.

Now, I am in contact with the people managing our central build service and I was able to move the version update before the removal of the .git files. Unfortunately, I just realized this still does not allow us to use lerna for version updates as they are not checking out branches but commits, which is a good thing as this ensures there will be no changes pushed back to the branch.

So once more, I would like to reopen the discussion: Why should lerna version need the code to be on a branch, when no git features are used?
You said that git is needed to determine what changed since the last tagged release in order to determine which packages need a version update. This is unnecessary for the default locked mode, isn't it? Additionally, it can be skipped with the --force-publish option and should not be necessary in that case either.

Looking at the implementation of the command, I do not see where the currentBranch is even used outside of the git related flags:

lerna/commands/version/index.js

Line 88 in c78a86c

this.currentBranch = getCurrentBranch(this.execOpts);

I wonder whether just replacing this:

lerna/commands/version/index.js

Line 90 in c78a86c

if (this.currentBranch === "HEAD") {

with this:

if ((this.pushToRemote || this.options.allowBranch || this.commitAndTag) && this.currentBranch === "HEAD")

would already do the trick? (Well, I guess there is more to that, but I just do not believe that there is no getting around that, when this is clearly unused).

Let me know what you think. I am willing to help with this, as I think lerna is an awesome tool that takes away some of the complexity of maintaining a multipackage repo with dynamically generated packages. I want to use lerna, but at the moment I don't see any better solution than creating a script that updates the versions of my interdependent packages, or do you have better suggestions?

[evocateur]

this.currentBranch is used several places, and moreover git is still required to detect changes, even in the default fixed mode. We don't just version everything every release, and independent versioning only changes what versions are assigned and what pattern of git tags to use, not the change detection itself.

--push, --allow-branch, and --git-tag-version have no effect on collectUpdates (called here). It'll always return all packages, an implicit --force-publish, which is not how Lerna works.