Add ability to publish non-interactively without version bumping

[peijiesim]

Summary

This PR is in reference to #5623. It adds a new feature to make it possible to publish non-interactively without specifying a new version. The current version in package.json will be used if no new version is specified.

Test plan

> yarn publish --non-interactive
yarn publish v1.6.0
[1/4] Bumping version...
info Current version: 1.6.0
[2/4] Logging in...
[3/4] Publishing...

[BYK]

This is nice but it looks like a breaking change to me. What do you think? Do you think anyone out there would be relying on this old behavior?

[peijiesim]

Hi @BYK, I'm still relatively new to npm/yarn and I'm not too familiar with the its history so I'd appreciate it if someone with more experience can provide his/her input. At the very least, I think this fixes the behavior in which running yarn publish --non-interactive still prompts for a new version.

[BYK]

@rally25rs @bestander @arcanis @kaylieEB

[rally25rs]

In the interest of not changing the existing functionality, what do you think about putting this behind a flag like #5670 added? Something like --current ?

yarn version [--current|--patch|--minor|--major]

[arcanis]

I'm not sure I understand exactly how the behavior changes from the old command line to the new one. Just to be sure I'm not making wrong assumptions, @peijiesim can you describe what are the affected command lines and how they change?

[peijiesim]

@arcanis yarn publish --non-interactive --new-version <version> requires that a user specify the version and produces an error otherwise. The change introduced in this PR allows a user to only run yarn publish --non-interactive and the current version in package.json will be used as the "new version".

[xentek]

tl;dr: Merge it as is. This branch is what --non-interactive should be doing already.

---

While I personally would have more closely followed the semantics of npm version and npm publish when implementing yarn publish ... it's too late for that now (at least until maybe yarn 2.0 🙏).

As for whether or not this should be considered a breaking change.... I personally think anyone's original hope for yarn publish --non-interactive was for it work like it does on this branch.

The only behavior of yarn publish --non-interactive without --new-version that anyone might be relying on is that it throws an error and exits. And while this serves as an early warning, wouldn't the registry they are publishing to also throw an error if the version they are trying to publish already exists?

In other words... everyone successfully using yarn publish --non-interactive is already doing so with the --new-version flag, and that accepting this branch is highly unlikely to upset any shell scripts or CI processes.

In fact, I'm wondering if really any difference between yarn publish --new-version and yarn publish --non-interactive --new-vesion -- other than maybe prompting to login to the registry if the token isn't in found in .yarnrc?

But I digress...

So, while the error (and possibly the exit code) would change if this branch was to be merged as is, I would further argue that the folks depending on the specific error condition caused by the lack of --new-version is going to be at or approaching 0. They have either switched back to npm publish (as I'm about to do) or they have figured out how to live with specifying --new-version in their shell scripts.

Thanks for making and maintaining yarn. I'm a fan... except when it comes time to publish. ✌️

[xentek]

@BYK ☝️

[arcanis]

I'd hold on this change until the v2, since we've been talking about normalizing the command line options.

[BYK]

@xentek thank you very much for the detailed response!

The only behavior of yarn publish --non-interactive without --new-version that anyone might be relying on is that it throws an error and exits. And while this serves as an early warning, wouldn't the registry they are publishing to also throw an error if the version they are trying to publish already exists?

Non-interactive mode can also be triggered if the CI environment variable is set, such as on TravisCI etc. end this is my main worry. I don't know if this is a big deal though after reading your response.

@arcanis

I'd hold on this change until the v2, since we've been talking about normalizing the command line options.

This PR seems to be solving a pain point with minimal changes. Are you sure holding it back indefinitely until we come up with a good plan for the 2.0 CLI and then deliver on it?

[xentek]

@BYK @arcanis thanks for taking another look at this

[arcanis]

Ok, I see no reason to block it right now, let's merge it 🙂