lerna publish --canary publishes broken packages

lerna publish --canary only looks at HEAD to determine what packages changed. This means that a package can be published without correct dependencies if those dependencies were changed in an earlier commit. I believe that --canary only operating on the HEAD commit is intentional, but I’m not sure how to achieve the “nightly release” behavior that this flag is supposed to provide.

I read through a few issues about the --canary and this may be a duplicate but I decided to create a new issue to share my use case and describe the problems im running into.

Expected Behavior

Every package published by lerna publish --canary should have dependencies that align with the state of the repo when the publish was run.

Current Behavior

Since lerna publish --canary only looks at the HEAD for changes it can publish broken packages. For an example, see the “Steps to Reproduce” section

Possible Solution

One solution of this could be to add --changed to lerna publish like https://github.com/lerna/lerna/issues/962 suggested

As a workaround I could use --force-publish "*" or try to replicate the --since flag using --force-publish and lerna list --since. I could also stop using the --canary flag but then I would lose its ability to automatically increment the -alpha.X suffix.

Steps to Reproduce (for bugs)

Do the following in a monorepo with package-a and package-b where package-a depends on package-b

1. Commit a new feature to package-b and run lerna publish --canary. lerna releases package-a@1.0.0-alpha.0 and package-b@1.0.0-alpha.0. package-a will depend on package-b@1.0.0-alpha.0 as expected.
2. Commit a new feature to package-a and run lerna publish --canary. lerna releases package-a@1.0.0-alpha.1 that depends on package-b@1.0.0. package-a will be broken if it uses a feature introduced in a previous commit and therefore is only available in package-b’s canary

lerna.json

I was using a pretty basic config:

{
  "packages": [
    "packages/*"
  ],
  "npmClient": "npm",
  "version": "1.0.1"
}

Context

I have a monorepo containing a few apps and libraries that are used by the apps. I want to run lerna publish --canary in CI for each commit to the master branch and a lot of the apps end up getting broken canaries as they are not using the correct versions of the libraries.

Your Environment

Executable	Version
lerna --version	3.13.4
npm --version	6.4.1
yarn --version	1.13.0
node --version	10.15.1

OS	Version
macOS Mojave	10.14.4

[jakewhelan]

@NMinhNguyen This is sorely needed.

Right now we’re using a hack to workaround this, but it’s unpleasant:

lerna publish --canary --preid next.$(git rev-parse --short HEAD)

Produces:

my-package@0.0.1-next.604b79a7.4

Where the trailing .4 is the remainder of the (broken) canary versioning.

[bimbiltu]

@dimaShin The simple workaround is to just pass the --force-publish flag to lerna publish --canary which will make it publish a canary for every package in your monorepo.

If for some reason you don’t want to publish all those extra packages you could also write a script that gets the intersection of lerna changed --json (packages changed since last publish) and lerna list --since $GIT_PREVIOUS_SUCCESSFUL_COMMIT^ --include-filtered-dependencies --json (uses jenkins specific var to get packages changed in commits you added to master). This would give you the minimal set of packages to pass to the --force-publish argument.