Release workflow customization?

[alecmev]

Context

We have a hybrid setup, consisting of a monorepo for newer code and a couple of legacy repos consuming packages from that monorepo, published to a private registry. We don't care about changelogs or granular versioning, we just want to be able to use a "point in time" snapshot of the monorepo elsewhere. There are only "major" and "prerelease" versions.

Current setup

This is our Lerna config:

{
  "$schema": "node_modules/lerna/schemas/lerna-schema.json",
  "npmClient": "yarn",
  "version": "123.0.0",
  "command": {
    "version": {
      "exact": true,
      "forcePublish": true,
      "private": false
    }
  }
}

And we release exclusively through CI, approximately like so:

yarn lerna version ${{ inputs.prerelease && 'prerelease' || 'major' }} \
  --preid ${{ github.ref_name }} \
  --yes

yarn workspaces foreach \
  --all \
  --no-private \
  --verbose \
  npm publish \
  --tolerate-republish \
  --tag ${{ inputs.prerelease && github.ref_name || 'latest' }}

This simply bumps all versions of everything, either to ${MAJOR+1}.0.0, or to ${MAJOR}.0.1-branch-name-${N}.

Problem

I don't see a way to accomplish this with one change. At very least it doesn't have a non-interactive mode. Is this too custom for oneRepo, and I should stick to Lerna? Or would you do it differently if this were your setup?

[paularmstrong]

This is one of the places that oneRepo is pretty opinionated about… which is, "don't do that" – favoring best practices and correctness.

I've been part of organizations where we had the type of flow you've got (but using semantic-release), and immediately moved away from it because it was too difficult to ensure legacy repos got updated (if ever) when major versions kept happening for every commit. We found that they would often lag and we'd forget what the breaking changes were and eventually end up just ignoring them completely.

While I completely discourage what you want here… I can see the utility of it and I would be happy to consider a PR that would enable something like…

one change version --all --yes

Where --yes/-y is an argument that bypasses the confirmation prompt. Also note that --all/-a may require some fixes to filter out private workspaces, because I don't think that's happening and will cause the command to crash.

This already doesn't require change entries, because it will take git commits into account.

May also want to consider:

• option to not write changelogs
  • I'm not 100% on this one, as I think it might just cause confusion in some workflows
• option to specify what semantic version to bump
  • --force-version=[type] – should be hidden so it only shows under --help --show-advanced
• … probably more, I will come back to this after further thought