`publish` should continue if git tag exists

I have a mono-repo of 20+ modules. My private, self-hosted registry supports publishing the same version more than once (poor practice, I know, but that’s not the point). If I run lerna publish, and one of the resulting git tags already exist, then the publish process fails at some unknown point in the process, and most of my modules are left unpublished (but bumped in the package.json files).

Expected Behavior

If tags are unsafe to create/push, then this should be the last step (specifically, after actually publishing the modules). If it’s possible to make the operation of creating and pushing a git tag safer, then this can be done, so at least the rest of the modules can be published to reflect their new version on the filesystem.

Current Behavior

Described in the opening paragraph

lerna.json

{
  "packages": [
    "deployment/*",
    "packages/pdf-*",
    "tools/packages/*"
  ],
  "version": "independent",
  "npmClient": "yarn"
}

lerna-debug.log

199 error Error: Command failed: git tag xxx@1.0.3 -m xxx@1.0.3
199 error fatal: tag 'xxx@1.0.3' already exists
199 error
199 error     at makeError (/xxx/node_modules/execa/index.js:174:9)
199 error     at Promise.all.then.arr (/xxx/node_modules/execa/index.js:278:16)

Your Environment

Executable	Version
lerna --version	3.10.7
npm --version	6.4.1
yarn --version	1.13.1
node --version	10.15.0

OS	Version
NAME	VERSION
macOS Mojave	10.14.3 beta

[WoodyWoodsta]

TL;DR: Lerna won’t support duplicate version tags, nor will it support publishing duplicate versions of a package to any registry, regardless of its (mis-)capabilities.

I understand this and support it. But I think what I am trying to highlight is that currently, Lerna makes the assumption that if a git tag of a particular version exists, then that version definitely exists on the registry (and the important point here is that it makes this assumption in that order - I think this would no longer be an issue if the registry was the point of truth). At the same time, its error handling during publish is brittle, which introduces a significantly heightened risk of modules going out of sync. It’s a command line interface, a user tool. It cannot expect a) network and environment conditions to be stable at all times of operation and b) user’s to be 100% correct in their use of the CLI. The fact that there are a number of other, similar issues (https://github.com/lerna/lerna/issues/1917, https://github.com/lerna/lerna/issues/1912, https://github.com/lerna/lerna/issues/455, https://github.com/lerna/lerna/issues/1785, https://github.com/lerna/lerna/issues/1709, https://github.com/lerna/lerna/issues/1668, https://github.com/lerna/lerna/issues/524, https://github.com/lerna/lerna/issues/1578, https://github.com/lerna/lerna/issues/1643, https://github.com/lerna/lerna/issues/1813) illustrates this point.

In any case, there is absolutely no obligation for the tool to respect the patchy, intermittent nature of web technology, and as such, Lerna is not doing anything wrong. I think that this is just an area for improvement, in making the experience of using Lerna better, especially for very large projects (high number of modules) as well as those learning how to use it and the registries. Feel free to close if you wish!

[evocateur]

@WoodyWoodsta I appreciate your sensitive analysis (and digging through the issues to find those you linked)!

#1767 sketches out a lot of my goals for lerna publish in the next major version. One of them is to teach lerna publish how to automatically infer from-git, from-package, and “nightly”/--canary publish (which depends on lerna version being completely severed).