Auto: "auto canary" in monorepo with beta version is failing

Also, the publishConfig.directory field in each package's package.json is not being respected.

I'll take a look at this!

1. The version is being bumped from 9.0.0-beta.33 to 9.0.1-canary.809.1.1a2be58f.0 when it should be 9.0.0-canary... instead.

I have opened #609 to get rid of the extra hash in there. The .0 part of the version is because we the --preid flag. We need this for the rest of the version so it can't really go away.

@hipstersmoothie Oh I wasn't complaining about that. I just didn't want to take the time to type out the hash. 😆 That sentence is actually pointing out how it's 9.0.1 when it should be 9.0.0 still.

Ah, I see. In that case that is expected behavior. The canary version is the simulated "next" version. For example:

PR has major label => The canary with those changes contains those major changes and should be a new major version

The reason it went to 9.0.1 is because we default to a patch when no label is found.

Oh ok. The latest tag currently points to 8.0.27, so I wouldn't expect auto canary to use 9.0.1 anyway. It must have been confused by the existence of 9.0.0-beta.33. Is there a way to force the version to stay at 9.0.0?

They way it behaves right now is it will look at the "Latest Release" and you local version and use the higher one. So in this case that resolved to 9.0.0-beta.33.

Is there a way to force the version to stay at 9.0.0?

Locally if I run lerna with prerelease instead of preminor the version doesn't increment. To get prerelease to the canary command we could add an extra flag or use a prerelease label, but the feature wouldn't be automatic.

It fails to publish to npm, saying You cannot publish over the previously published versions: 9.0.0-beta.33

This seems to be an issue around the package.jsons making their way into the dist folder. The prepare step is ran before anything auto does so the version is whatever was there at first. In this case "9.0.0-beta.33"

When lerna run its picks up this stale version of the package.json, which contains an already published version, and tries to publish again.

Locally if I run lerna with prerelease instead of preminor the version doesn't increment. To get prerelease to the canary command we could add an extra flag or use a prerelease label, but the feature wouldn't be automatic.

That should be good enough. Do you consider "running auto canary locally from a branch that builds off a beta/next version" to be an edge case? If not, maybe there should be automatic support here. Also, if I were to run auto canary from CI, will I still hit this edge case?

When lerna run its picks up this stale version of the package.json, which contains an already published version, and tries to publish again.

Lerna supports publishConfig.directory (see here), but maybe your integration with Lerna is somehow avoiding that code path.

It's this line that is the problem.

Because you do this thing where you copy over the package.json, readme, etc into the dist folder and then just publish that, we need to run the prepare script at a very specific time:

1. lerna version - changes package.json to canary version
2. prepare - final package put in dist folder
3. lerna publish - publishes package dist folder with correct version

So for this workflow you must let the lifecycle scripts run and ignoreScripts must be set to false (or just not at all).

Do you consider "running auto canary locally from a branch that builds off a beta/next version" to be an edge case? If not, maybe there should be automatic support here.

beta/next support really isn't built in yet but I will come back to this issue when I try to tackle it.

maybe your integration with Lerna is somehow avoiding that code path.

We aren't making any assumptions about the lerna usage so this shouldn't really be a problem. You can see here that we're just calling to lerna to do all the heavy lifting.

@aleclarson I was able to publish a canary after removing ignoreScripts. I think I have addressed everything in this issue, if I have please close!

Okay sweet! I have a workaround in place right now, so I won't be checking anytime soon.

I'll be sure to reopen if I get around to trying this again. ;)