yarnpkg / berry

📦🐈 Active development trunk for Yarn ⚒
https://yarnpkg.com
BSD 2-Clause "Simplified" License
7.4k stars 1.11k forks source link

`yarn version check` does not work well with "immediate" workflow #2569

Open borekb opened 3 years ago

borekb commented 3 years ago

I wanted to set up yarn version check on CI as advised here but I wonder how it's supposed to work with immediate version bumping (if at all). For example:

  1. I update my-package/index.js, bump version in package.json and commit this together.
  2. I push to GitHub, open a small PR but get this error:

    "my-package has been modified but doesn't have a release strategy attached"

I think that my project is in a correct state – the source code is in agreement with package.json version and there shouldn't be any need for a .yarn/versions/abc.yml file.

Technically, I think the key is the getUndecidedWorkspaces function:

https://github.com/yarnpkg/berry/blob/6bdf043bfee35ef61df2121885b3a086bb77154b/packages/plugin-version/sources/versionUtils.ts#L317-L332

I think it could be implemented so that for any modified workspace, it would also check whether it has a modified package.json#version field. If so, the workspace would become "decided".

Could this work? Good / bad idea?

barticus commented 2 years ago

I have the same problem. It would be good if the version could be compared to the main (or a specific) branch to determine if it has already been bumped. Alternatively, the git history could be used to check the file modifications since the last version bump.

penx commented 1 year ago

Having the same issue when bumping prerelease version via a PR.

I have a GitHub action that runs

yarn version apply --all --prerelease

...then commits any package.json updates and raise a PR.

yarn version check then fails on this PR due to the change to the package.json.

I think this can be fixed by adding a line below the bump:

yarn version apply --all --prerelease
yarn workspace my-workspace version decline -d

before committing