Feature Request: warn user on a per package basis

[jorenbroekema]

I was discussing changesets with a friend and we are a little worried that when making cross-package changes in our monorepo, we may forget / fail to add a changeset for all the packages that should be released. The changeset bot is pretty handy for a warning in general that there's no changeset for the PR, but we would like to get an overview actually for which packages our PR made changes for, and for which packages a changeset is made.

So we would get something like:

---

Changeset Bot
Hey, I see you're making changes to some packages that are not scheduled to release via a changeset:
✔️ package-a
❌ package-b
✔️ package-c
This might be intended, but I'm adding this message here to make sure :)

---

I wonder if this would interest you guys

[Noviny]

I was originally going to say 'no', but after thinking about it a bit more, I think the answer is 'yes', this would be a good addition to how the bot works.

There's an alternative if you want to really enforce this which is to block CI unless there's a changeset for each package in the PR which this bot wouldn't want to do. You can unblock CI by generating an empty changeset for a package that doesn't need a release. Sadly, the places I've seen this done are close-sourced.

[jorenbroekema]

I think for us it's more that we want the visibility that a PR changes X, Y & Z package, and only X and Z have a changeset. I don't think we would like to actually block the CI (e.g. in changeset action) if it's missing one.

So in that sense it's similar to the current bot behavior, which is just sending a message for visibility, but extended to have more information.

[Noviny]

Yeah I think this would be a good thing to add.

[Noviny]

I'd possibly hide it under a collapse so that it doesn't generate too long a comment.

[cristobal]

What's the status of this?

We have the same problem, we use changeset bots but it does not work well with a monorepo one often will forget to add changesets files.

The problem by enabling changesets files to be required on the whole repo is that it forces one to have changesets file even for directories that includes a package.json but only are deployments and not packages published to npm.

[nwalters512]

I think we're running into the same issue. We only use changesets for a portion of our repo (everything in a packages/ directory), but there are many other directories that we don't want to require changesets for. This is a blocker for using this bot, as the majority of PRs will not be touching the packages/ directory, and thus shouldn't get a comment that may mislead contributors.

[cristobal]

I think we're running into the same issue. We only use changesets for a portion of our repo (everything in a packages/ directory), but there are many other directories that we don't want to require changesets for. This is a blocker for using this bot, as the majority of PRs will not be touching the packages/ directory, and thus shouldn't get a comment that may mislead contributors.

Yeah we have the same issue at work, we created a script at work that incrementally applies all the changesets and reverts eventual apply's to package.json files in directories we don't want to be included when running the changeset version command.

Been thinking that there should be some way of in the changeset config.json to specify which packages or directory patterns to be included as part of changeset algorithm, and eventual individual settings per such specific package or directory patterns.

In many config systems one can tell which directories or packages should be considered to be included as part of their heuristics, this is a feature that seems to be missing here and many could benefit from.