How to tag and publish an initial v1.0.0 with conventional commits?

[rfgamaral]

I'm having a hard time figuring out how can I tag and publish an initial v1.0.0 with conventional commits using lerna publish.

This is my lerna.json:

{
  "version": "independent",
  "npmClient": "yarn",
  "useWorkspaces": true,
  "stream": true,
  "command": {
    "publish": {
      "registry": "http://localhost:4873",
      "verifyAccess": false
    },
    "version": {
      "allowBranch": "master",
      "conventionalCommits": true,
      "exact": true,
      "message": "chore(release): update release notes and package versions",
      "noCommitHooks": true
    }
  }
}

Now let's say I'm working on my first initial version and I have a single package (not relevant to have more for the purpose of this issue) which has "version": "1.0.0" in package.json.

If I make fix: ... commits, lerna publish will suggest the next version to be v1.0.1, if I make feat: ... commits, lerna publish will suggest the next version to be v1.1.0. Even if I set "version": "0.0.0" in package.json, fix: ... will lead to v0.0.1 and feat: ... will lead to v0.1.0.

The only I've found to have lerna publish to tag and publish the first version as v1.0.0 is to have the major version in package.json set to 0 (minor and patch can be anything) and then make a BREAKING CHANGE commit. That way lerna publish will suggest the next version to be v1.0.0.

But it doesn't feel right to add BREAKING CHANGE to a commit just for the purpose of tagging a first release as v1.0.0. There's not breaking change (it's the initial version after all) and that will be added to CHANGELOG.md, which doesn't make sense.

How can I tag and publish the first initial version of my package as v1.0.0 with a single entry on my CHANGELOG.md something like feat: initial version?

[rfgamaral]

After a bit more digging and testing I've realized I can just call lerna publish 1.0.0 to publish the first initial version, no matter the fixes, feats or breaking changes in commit messages (everything will be properly added to the CHANGELOG.md under 1.0.0).

[brianjquinn]

@rfgamaral - I have the same question/problem as your initial question. I have a build automating my publishing based on conventional-commits by calling lerna publish --yes with a lerna.json for publish that looks like this:

"publish": {
      "registry": "<redacted>",
      "message": "chore(release): Publish",
      "conventionalCommits": true,
      "allowBranch": "master",
      "ignoreChanges": [
        "*.test.js",
        "*.md",
        "Jenkinsfile",
        ".*",
        "commitlint.config.js"
      ]
    }

Since its automated and I can't on a case by case basis run lerna publish 1.0.0 for when new packages are created in my monorepo. The only workaround I've found is to set a new package's version to 0.0.1 and then associate a BREAKING CHANGE commit with that package so that it's published as 1.0.0, but as you mentioned the autogenerated change log is less than ideal. It mentions a BREAKING CHANGE in it, which is weird for an initial version.

However in the lerna changelog I noticed that for version 3.22.0 and this commit/PR specifically that version 0 will be preserved on BREAKING CHANGE commits associated with it ....

so how the heck do you automate releasing an initial version 1.0.0?

[inthegreenwild]

The only way I can see updating now would be to manually change packages to 1.0.0-alpha.0 and then run lerna conventional graduate on that.

The new system is inline with node but confusing, and to some degree a breaking change instead of a minor change.

Any other solutions for moving from 0.x.x => 1 after lerna 3.22.x? @evocateur

[brianjquinn]

yeah i understand aligning the behavior with node for 0.x.x, so no arguments there - it just seems like there is no automated way to initially create a package in a monorepo and publish it as 1.0.0 using conventional-commits ... running the conventional graduate makes sense, but I'm still unclear how I would automate that since you are required to specify the specific package you want to graduate (otherwise it automatically does all of the pre-release packages in a similar fashion to force publish) ... maybe the graduation process isn't meant to be automated with conventional commits, which is disappointing because otherwise it works flawlessly

[waldronmatt]

also currently looking for a way to automate this. tools like semantic release bump properly to v1 on initial publish