Automatically update `yarn.lock` after release

[ognis1205]

Is there an existing issue or pull request for this?

• [x] I have searched the existing issues and pull requests

Feature description

After releasing a new version of git-cliff, the yarn.lock files for npm packages managed in this repository often become outdated. Currently, updating them is a manual process, which is error-prone and sometimes forgotten.

Desired solution

Automatically regenerate or update yarn.lock files for the repository's npm packages whenever a new git-cliff release is published. This could be implemented using a GitHub Action triggered on release events.

Alternatives considered

• Manually running yarn install or yarn upgrade after each release and file a PR.

Additional context

• GitHub Marketplace has actions like "Create Pull Request" that could be used to automatically open a PR with the updated yarn.lock.
• This automation would reduce human errors and ensure downstream packages always use the latest git-cliff version.

[orhun]

Marking as good first issue.

[alerque]

This should happen before –or simultaneously with– the release process, not after. In other words whatever commit is tagged as the release point should already contain the matching lock file updates, either in a commit prior to the tagged one or the actual tagged one.

[orhun]

Hmm yeah, not sure how easy it is to do then.

cc @favna

[favna]

I'm not really tuned into the release process of this repository, but what about:

1. Make a release commit, tag it. DON'T push this yet to the remote
2. Update the lockfile, commit it
3. Squash the commits together
4. Move the tag to the newly squashed commit
5. Push everything to remote

This way it can be a separate-ish step still and may be easier to automate with the processes being separate?

[orhun]

The release process is documented here: https://github.com/orhun/git-cliff/blob/main/RELEASE.md

This way it can be a separate-ish step still and may be easier to automate with the processes being separate?

Hmm I don't really get what would be the benefit of that.

[ognis1205]

I looked into OSS projects with a setup similar to git-cliff, but as far as I know, I couldn't find any.

I think a release flow like this could also work:

• Create a temporary release branch (e.g., release/v1.2.3).
• Update package versions and optionalDependencies in the release branch.
• Publish Rust binary npm packages first, then the npm wrapper package.
• Run yarn install and commit the updated yarn.lock.
• Merge the release branch into main.
• Create a release tag (e.g., v1.2.3) on the merge commit in main.

The CHANGELOG could still be generated automatically on tag events in main:

on:
  push:
    tags:
      - "v*.*.*"

To automate publishing via CI, you can use a workflow like:

on:
  push:
    branches:
      - 'release/v*.*.*'

This way, the tagged commit always contains the correct yarn.lock and dependency versions.

I personally think this could be a viable approach, but I’m curious—what does everyone else think?

[orhun]

That would require an overhaul of the current cd.yml (which is already complex enough 😅): https://github.com/orhun/git-cliff/blob/main/.github/workflows/cd.yml

[ognis1205]

That would require an overhaul of the current cd.yml (which is already complex enough 😅): https://github.com/orhun/git-cliff/blob/main/.github/workflows/cd.yml

Yeah, keeping the changes minimal, it seems quite difficult to include the lockfile in the release with the current setup 😅. From my understanding, this would require changing the flow from publishing packages after a tag event to publishing first and then tagging/creating the release.

That's just my personal take, though — I'd love to hear what others think about this.

[alerque]

Most tooling has a way to get an advance simulation of an upcoming release (e.g. by setting an env var) before actually tagging it so that the tagged version can be consistent in lock files.

[ognis1205]

Most tooling has a way to get an advance simulation of an upcoming release (e.g. by setting an env var) before actually tagging it so that the tagged version can be consistent in lock files.

If I understand correctly, I think you're referring to things like npm version --no-git-tag-version or npm pack.

That said, in this case the issue seems to be that the optionalDependencies listed here:

https://github.com/orhun/git-cliff/blob/ee9f7428958d2b602f0c82749f8ed8da7214fac8/npm/git-cliff/package.json#L93-L100

are binary npm packages for git-cliff, which don't exist in the registry until they're actually published. So even if we try something like yarn install --mode update-lockfile, it would fail as long as the binaries for the new version aren't available in the registry yet.

In other words, even if we bump the wrapper package version locally with npm version --no-git-tag-version, I think we'd still run into the same issue. Or am I misunderstanding something here?