[getLastTagNotInBaseBranch] next breaks when tags are created per-package in an independent monorepo

[10hendersonm]

Describe the bug

Running npx auto shipit against origin/next, auto.next is calling getLastTagNotInBaseBranch , which throws when trying to run semver's gt or lt against a tag like @demo/core@1.2.3.

To Reproduce

Attempt to publish the next branch of a monorepo with independent, exact npm packages tagged individually. (See below for an example of what our tags look like)

Expected behavior

Should publish packages.

Screenshots

Environment information:

Appears to exit with code 1 without useful info.

ℹ  info      getPreviousVersion for package praxis-scripts

Additional context

My team is currently working auto into our publication pipeline. Our monorepo uses independent versioning, and tags are generated per-package both in our current base lerna publication model as well as when we use auto to ship next.

@bmuenzenmeyer may be able to clarify how we've gotten there through config. Here's what our tags currently look like:

[
  '@monorepo/utils@6.0.1-next.0',
  '@monorepo/styles@6.0.1-next.0',
  '@monorepo/docs@2.2.1-next.0',
  '@monorepo/core@6.0.1-next.0',
  '@monorepo/models@3.2.1-next.0',
  '@monorepo/utils@6.0.0',
  '@monorepo/styles@6.0.0',
  '@monorepo/core@6.0.0',
  '@monorepo/utils@5.0.0',
  '@monorepo/styles@5.0.0',
  '@monorepo/utils@4.3.0',
  '@monorepo/core@4.3.0',
  '@monorepo/internals@2.1.0',
  '@monorepo/utils@4.2.0',
  '@monorepo/styles@4.2.0',
  '@monorepo/docs@2.2.0',
  '@monorepo/core@4.2.0',
  '@monorepo/models@3.2.0',
  '@monorepo/internals@2.0.1',
  '@monorepo/utils@4.1.1',
  '@monorepo/styles@4.1.1',
  '@monorepo/docs@2.1.1',
  '@monorepo/core@4.1.1',
  '@monorepo/models@3.1.1',
  '@monorepo/utils@4.1.1-next.3',
  '@monorepo/docs@2.1.1-next.3',
  '@monorepo/core@4.1.1-next.3',
  '@monorepo/utils@4.1.1-next.2',
  '@monorepo/docs@2.1.1-next.2',
  '@monorepo/core@4.1.1-next.2',
  '@monorepo/utils@4.1.1-next.1',
  '@monorepo/docs@2.1.1-next.1',
  '@monorepo/core@4.1.1-next.1',
  '@monorepo/internals@2.0.1-next.0',
  '@monorepo/utils@4.1.1-next.0',
  '@monorepo/styles@4.1.1-next.0',
  '@monorepo/docs@2.1.1-next.0',
  '@monorepo/core@4.1.1-next.0',
  '@monorepo/models@3.1.1-next.0',
  '@monorepo/utils@4.1.0',
  '@monorepo/styles@4.1.0',
  '@monorepo/docs@2.1.0',
  '@monorepo/core@4.1.0',
  '@monorepo/models@3.1.0',
  '@monorepo/core@5.1.0',
  '@monorepo/core@5.0.0',
  '@monorepo/utils@4.0.0',
  '@monorepo/styles@4.0.0',
  '@monorepo/core@4.0.0',
  '@monorepo/models@3.0.0',
  '@monorepo/utils@3.0.0',
  '@monorepo/styles@3.0.0',
  '@monorepo/docs@2.0.0',
  '@monorepo/core@3.0.0',
  '@monorepo/core@2.1.1',
  '@monorepo/core@2.1.0',
  '@monorepo/core@2.0.2',
  '@monorepo/core@2.0.1',
  '@monorepo/internals@2.0.0',
  '@monorepo/utils@2.0.0',
  '@monorepo/styles@2.0.0',
  '@monorepo/core@2.0.0',
  '@monorepo/models@2.0.0',
]

Unfortunately, I threw some code at this problem and realized I'm out of my depth. I have a list of questions, and while I can answer them for the single functional use case, I won't be able to isolate all use cases.

• Could you just coerce the versions? Would that be OK, even when prereleases (1.2.3-beta.0) exist?
• How do you sort prereleases?
  • Do you even need to sort prereleases? Can you just assume the first one is the "latest" one?
• How would you determine which package's version is returned?
  • Ex: Shown above, we published the top 5 tags simultaneously. Is returning any one tag OK?

Our solution at the moment is to pivot to fixed versioning, which solves a number of other problems for us, but we're still determining all the ramifications of that change and may need to turn back to independent.

[10hendersonm]

Here's an example test to validate this (injected here). I don't know what the snapshot value should be (see the questions above), but the test fails via throw before it gets that far currently.

test("handles tags with package names", async () => {
      const baseTags = [
        '@monorepo/models@2.0.0',
        '@monorepo/core@2.0.0',
        '@monorepo/styles@2.0.0',
        '@monorepo/utils@2.0.0',
        '@monorepo/internals@2.0.0',
        '@monorepo/core@2.0.1',
        '@monorepo/core@2.0.2',
        '@monorepo/core@2.1.0',
        '@monorepo/core@2.1.1',
        '@monorepo/core@3.0.0',
        '@monorepo/docs@2.0.0',
        '@monorepo/styles@3.0.0',
        '@monorepo/utils@3.0.0',
        '@monorepo/models@3.0.0',
        '@monorepo/core@4.0.0',
        '@monorepo/styles@4.0.0',
        '@monorepo/utils@4.0.0',
        '@monorepo/core@5.0.0',
        '@monorepo/core@5.1.0',
        '@monorepo/models@3.1.0',
        '@monorepo/core@4.1.0',
        '@monorepo/docs@2.1.0',
        '@monorepo/styles@4.1.0',
        '@monorepo/utils@4.1.0',
        '@monorepo/models@3.1.1-next.0',
        '@monorepo/core@4.1.1-next.0',
        '@monorepo/docs@2.1.1-next.0',
        '@monorepo/styles@4.1.1-next.0',
        '@monorepo/utils@4.1.1-next.0',
        '@monorepo/internals@2.0.1-next.0',
        '@monorepo/core@4.1.1-next.1',
        '@monorepo/docs@2.1.1-next.1',
        '@monorepo/utils@4.1.1-next.1',
        '@monorepo/core@4.1.1-next.2',
        '@monorepo/docs@2.1.1-next.2',
        '@monorepo/utils@4.1.1-next.2',
        '@monorepo/core@4.1.1-next.3',
        '@monorepo/docs@2.1.1-next.3',
        '@monorepo/utils@4.1.1-next.3',
        '@monorepo/models@3.1.1',
        '@monorepo/core@4.1.1',
        '@monorepo/docs@2.1.1',
        '@monorepo/styles@4.1.1',
        '@monorepo/utils@4.1.1',
        '@monorepo/internals@2.0.1',
        '@monorepo/models@3.2.0',
        '@monorepo/core@4.2.0',
        '@monorepo/docs@2.2.0',
        '@monorepo/styles@4.2.0',
        '@monorepo/utils@4.2.0',
        '@monorepo/internals@2.1.0',
        '@monorepo/core@4.3.0',
        '@monorepo/utils@4.3.0',
        '@monorepo/styles@5.0.0',
        '@monorepo/utils@5.0.0',
        '@monorepo/core@6.0.0',
        '@monorepo/styles@6.0.0',
        '@monorepo/utils@6.0.0',
      ]
      const branchTags = [
        '@monorepo/models@2.0.0',
        '@monorepo/core@2.0.0',
        '@monorepo/styles@2.0.0',
        '@monorepo/utils@2.0.0',
        '@monorepo/internals@2.0.0',
        '@monorepo/core@2.0.1',
        '@monorepo/core@2.0.2',
        '@monorepo/core@2.1.0',
        '@monorepo/core@2.1.1',
        '@monorepo/core@3.0.0',
        '@monorepo/docs@2.0.0',
        '@monorepo/styles@3.0.0',
        '@monorepo/utils@3.0.0',
        '@monorepo/models@3.0.0',
        '@monorepo/core@4.0.0',
        '@monorepo/styles@4.0.0',
        '@monorepo/utils@4.0.0',
        '@monorepo/core@5.0.0',
        '@monorepo/core@5.1.0',
        '@monorepo/models@3.1.0',
        '@monorepo/core@4.1.0',
        '@monorepo/docs@2.1.0',
        '@monorepo/styles@4.1.0',
        '@monorepo/utils@4.1.0',
        '@monorepo/models@3.1.1-next.0',
        '@monorepo/core@4.1.1-next.0',
        '@monorepo/docs@2.1.1-next.0',
        '@monorepo/styles@4.1.1-next.0',
        '@monorepo/utils@4.1.1-next.0',
        '@monorepo/internals@2.0.1-next.0',
        '@monorepo/core@4.1.1-next.1',
        '@monorepo/docs@2.1.1-next.1',
        '@monorepo/utils@4.1.1-next.1',
        '@monorepo/core@4.1.1-next.2',
        '@monorepo/docs@2.1.1-next.2',
        '@monorepo/utils@4.1.1-next.2',
        '@monorepo/core@4.1.1-next.3',
        '@monorepo/docs@2.1.1-next.3',
        '@monorepo/utils@4.1.1-next.3',
        '@monorepo/models@3.1.1',
        '@monorepo/core@4.1.1',
        '@monorepo/docs@2.1.1',
        '@monorepo/styles@4.1.1',
        '@monorepo/utils@4.1.1',
        '@monorepo/internals@2.0.1',
        '@monorepo/models@3.2.0',
        '@monorepo/core@4.2.0',
        '@monorepo/docs@2.2.0',
        '@monorepo/styles@4.2.0',
        '@monorepo/utils@4.2.0',
        '@monorepo/internals@2.1.0',
        '@monorepo/core@4.3.0',
        '@monorepo/utils@4.3.0',
        '@monorepo/styles@5.0.0',
        '@monorepo/utils@5.0.0',
        '@monorepo/core@6.0.0',
        '@monorepo/styles@6.0.0',
        '@monorepo/utils@6.0.0',
        '@monorepo/models@3.2.1-next.0',
        '@monorepo/core@6.0.1-next.0',
        '@monorepo/docs@2.2.1-next.0',
        '@monorepo/styles@6.0.1-next.0',
        '@monorepo/utils@6.0.1-next.0',
      ]

      const gh = new Git(options);

      gh.getTags = (ref: string) => {
        if (ref === "origin/master") {
          return Promise.resolve(baseTags);
        }

        return Promise.resolve(branchTags);
      };

      expect(await gh.getTagNotInBaseBranch("branch")).toMatchInlineSnapshot();
    });

[bmuenzenmeyer]

• Could you just coerce the versions? Would that be OK, even when prereleases (1.2.3-beta.0) exist?

this blocked me for a long time, (and I wondered if semver coercion would fix it too!)

then I started writing a plugin that made a lot of assumptions and essentially got us into a quasi-fixed mode anyways, because it was always looking for a specific entrypoint package as the needle in our haystack, such as @monorepo/core

[hipstersmoothie]

Could you just coerce the versions? Would that be OK, even when prereleases (1.2.3-beta.0) exist?

I'm not sure. Gotta play around with this

How do you sort prereleases?
Do you even need to sort prereleases? Can you just assume the first one is the "latest" one?

We support multiple pre release branches. So thats why we try to find the greatest one in the branch. But to your point maybe this could just the latest tag and not try to find the "greatest" one

How would you determine which package's version is returned?
Ex: Shown above, we published the top 5 tags simultaneously. Is returning any one tag OK?

In next that tag is only used to calculate the commits in the release + generate release notes. Most of the work done here is done by lerna in the npm plugin. That's why the tag version returned doesn't really matter, it just has to be one the encompasses the right commits.

---

Thanks for the test case! I'll throw this in a PR and get that case working

[hipstersmoothie]

Keeping this issue open for discussion and other problems/question you guys might have

[adierkens]

🚀 Issue was released in v9.38.1 🚀

[10hendersonm]

Worked great! We'll do some further validation today. We're still deciding if we should pivot our project to fixed, but this allows us to equally evaluate the two options.

[hipstersmoothie]

In my opinion lerna based monorepos works best with fixed versioning. It makes it far easier to reason about the version you should have.

My teammate's opinion:

much harder to know what's up to date vs what just hasn't been updated in a while
with a single version, you just move up all of the versions at once and you can still add/remove dependencies if you want to

In the future auto might have a better monorepo experience with #917. But that won't be for awhile

[10hendersonm]

Worked great! We'll do some further validation today. We're still deciding if we should pivot our project to fixed, but this allows us to equally evaluate the two options.

Whelp, I actually failed to validate it (I was on master rather than next, and I forgot to un-link my local version which hadn't been pulled and thus was out of date), but I can now confirm that it worked great, for real.