fix(release): unblock the release push and stop spurious major bumps - #235
Merged
Conversation
The release job installs dependencies, which runs `lefthook install` and arms the repository's pre-push hooks inside the CI checkout. Pushing the release commit then ran the native test suites, which cannot pass on the Linux release runner: the Swift suite needs xcodebuild and the Kotlin suite needs an `expo prebuild` Android project. Disable lefthook for the job so the push succeeds; CI already gates these suites on main. Also drop the `@use-voltra/android` and `@use-voltra/ios` peer dependencies from the CLI. Changesets bumps peer dependents by major, and because both packages sit in the `fixed` group they are bumped on every release, so every release resolved to a major version. The declarations were inert regardless: the CLI resolves both packages from the consuming app's project root, not from its own dependency tree.
Removing the peer dependencies left the lockfile out of sync, which broke `pnpm install --frozen-lockfile`. `autoInstallPeers` had resolved both bare `*` peers to published 1.4.1 tarballs rather than workspace links, so this prunes those importer entries along with the package and snapshot records that only they referenced.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What is this?
The Release workflow cannot currently publish. Its first run failed while pushing the release commit, leaving the version bump and build completed but nothing pushed, tagged, or published. Separately, the release it was attempting was numbered
3.0.0when the pending version plans only justify a minor bump to2.2.0. This fixes both.How does it work?
Installing dependencies runs the root
preparescript,lefthook install, which arms the repository's pre-push hooks inside the CI checkout. Pushing the release commit therefore ran the native test suites, neither of which can pass on the Linux release runner: the Swift suite needsxcodebuild, and the Kotlin suite buildsexample/android, a git-ignored directory generated byexpo prebuild. Both hooks fired because their guard compares againstorigin/main, and the release commit changes the client packages' versions. The release job now setsLEFTHOOK: 0and passes--no-verifyon both pushes. These suites already gatemainthrough required CI checks, and the release commit only layers version and changelog changes on top of a commit that passed them.The version number came from a second, independent problem. Changesets promotes any package that peer-depends on a released package to a major bump, and it does so even for a
*range that can never fall out of range. The CLI declared@use-voltra/androidand@use-voltra/iosas optional peers, and both sit in thefixedgroup in.changeset/config.json, so they are bumped on every release. That made the CLI major on every release, and thefixedgroup then propagated that major to all twelve published packages — meaning3.0.0, then4.0.0, and so on, regardless of content. Removing the two declarations restores the intended bump.Those declarations carried no weight.
packages/cli/src/dependencies/platformPackages.tsresolves both packages throughcreateRequirerooted at the consuming app'spackage.json, not the CLI's own dependency tree, so peer hoisting never affected whether the CLI works. The CLI already reports both packages as missing with an actionable message, and@use-voltra/android-client,@use-voltra/ios-client, and@use-voltra/metroare resolved the same way without ever being declared as peers.Why is this useful?
Releases can be cut again, and they carry the version number their changesets describe instead of consuming a major on every publish.