Repository navigation
changeset status errors when no publishable package has been modified #496
Description
Affected Packages
@changesets/cli
Problem
Hello and thank you for changesets! It looks great and I'm excited to adopt it where I work 🙂
I'm migrating our versioning/publishing automation from rush to changesets, and changesets is a much lighter solution for my goals.
The only thing I miss from rush is their equivalent of changeset status, rush change -v. It automatically detects if any changes in your working branch actually affect a publishable package before erroring. That means if I have a branch that only makes changes to i.e. monorepo tooling, rush change -v does not error.
TL;DR; if I modify e.g. the root package.json of a monorepo and run changeset status --since=main, it will error, even though I didn't modify any publishable packages.
Proposed solution
It looks like currently, changeset status --since=branch only checks for new changeset files in .changeset/ to determine if it should error.
Ideally, it would also check if the diff since branch includes changes to files within packages folders before erroring.
Activity
Andarist commentedon Nov 27, 2020
Out of curiosity. What you have found to be difficult with Rush? Is there anything that was particularly good about it?
Well, that would be a breaking change right now - but the behavior you want would be possible to be implemented under a new flag. It should be fairly easy. We'd have to prevent this:
https://github.com/atlassian/changesets/blob/c6d38b579bdfddc22714c352c3459d04d1745326/packages/cli/src/commands/status/index.ts#L43
based on similar logic to this:
https://github.com/atlassian/changesets/blob/c6d38b579bdfddc22714c352c3459d04d1745326/packages/cli/src/commands/add/index.ts#L30
Would you be willing to work on adding this?
vitorbal commentedon Nov 30, 2020
Well, Rush is more of a "kitchen-sink" tool for monorepos, with tons of features besides versioning – some of which we were just not interested in. The biggest value we get out of rush today is the versioning/publishing automation, so it felt overkill to use Rush for it.
We're also using yarn v1, but rush is more tuned towards pnpm or yarn v2 – we had a lot of trouble installing/updating dependencies with rush, probably due to the way it interacts with yarn v1. We often had to force a full reinstall to get the updates to show up in yarn.lock.
The documentation is exceptionally good. And all config files have inline comments explaining every field too. They also have an active gitter channel.
vitorbal commentedon Nov 30, 2020
Thanks for the pointers, I can definitely take a look! I'll see if I have time this week for a PR 🙂