yarnpkg / berry

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

[Feature] Ignore private workspaces when using `yarn version` #4223

Open mrtnzlml opened 2 years ago

mrtnzlml commented 2 years ago

Describe the user story

I have mix of public and private packages in my monorepo. I really like to be using yarn version plugin as it simplifies everything significantly. However, it get's a bit annoying that private workspaces are failing on CI (until I mark them as declined manually). CI is failing because I am running there yarn version check (to make sure public workspaces are versioned properly). Mentioned fail:

YN0000: Your PR was started right after 3f[9](https://github.com/adeira/universe/runs/5544973237?check_suite_focus=true#step:5:9)1484 Update Rust crate reqwest to 0.11.[10](https://github.com/adeira/universe/runs/5544973237?check_suite_focus=true#step:5:10)
➤ YN0000: You have changed the following files since then:

➤ YN0000: /home/runner/work/universe/universe/src/monorepo-shipit/config/abacus-kochka-mrtnzlml.js

➤ YN0000: @adeira/monorepo-shipit@workspace:src/monorepo-shipit has been modified but doesn't have a release strategy attached

➤ YN0000: This command detected that at least some workspaces have received modifications without explicit instructions as to how they had to be released (if needed).
➤ YN0000: To correct these errors, run `yarn version check --interactive` then follow the instructions.
➤ YN0000: Failed with errors in 0s 241ms

Describe the solution you'd like

I would like to be able to ignore private workspaces when using yarn version plugin. I am aware of changesetIgnorePatterns in .yarnrc.yml but I don't think it's a good solution since the monorepo is changing often and it would be complicated to keep it in sync.

Describe the drawbacks of your solution

I am not aware of any drawbacks as this feature should be opt-in via something like --ignore-private-workspaces.

Describe alternatives you've considered

I considered using changesetIgnorePatterns but, as I mentioned above, it might be quite challenging to keep it in sync with the monorepo long-term.

smoores-dev commented 2 years ago

I was just looking for such a feature! This seems like a fairly elegant solution. We do use changesetIgnorePatterns, but even that isn't sufficient, I don't think. Since our private packages depend on our public one, we're prompted to decline version bumps for our public packages any time our private packages change!

arcanis commented 2 years ago

Do you have a version field in your private workspace? Iirc removing it should solve this use case, as we only request bumps for versioned packages