Release automation unblocked after tag collision fix
Release-please was managing two packages and colliding on git tags whenever versions diverged — five PRs failed to publish. The root package is private, never published to npm, and shouldn't have been in the release pipeline at all.
The monorepo's release automation was stuck. A cascade of PRs (#27 through #31) attempted to publish @gitpulse/cli to npm, but each one failed at the git tagging step. The root cause: release-please was managing both the root package (".") and the cli package with include-component-in-tag: false, forcing them to share a single tag namespace. When versions diverged — which happened any time only one package had changes — the collision was immediate.
Removing the root package from release-please's configuration was the straightforward fix. The root is private, has no consumers, and never gets published to npm. There's no reason to manage its version automatically. With only @gitpulse/cli tracked, there's one tag namespace and one release lifecycle. No collision is possible.
The version also needed resetting. A phantom 0.1.2 existed in package.json from the failed release attempts, but it was never tagged in git and never reached npm. Rolling back to 0.1.1 — the last version that actually shipped — ensures the next release creates a clean v0.1.2 tag in an empty namespace.
The workflow also hedges against ambiguity in release-please-action's output format. Without a root package configured, the action might emit either bare outputs (release_created, tag_name, major) or path-scoped ones (cli--release_created, etc.). The workflow now coalesces both forms so downstream jobs work regardless of which shape is emitted on any given run.