You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feature Request: warn user on a per package basis #11
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 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.
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.
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.
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.
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.
Activity
Noviny commentedon Sep 23, 2020
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
emptychangeset for a package that doesn't need a release. Sadly, the places I've seen this done are close-sourced.jorenbroekema commentedon Sep 27, 2020
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 commentedon Oct 1, 2020
Yeah I think this would be a good thing to add.
Noviny commentedon Oct 1, 2020
I'd possibly hide it under a collapse so that it doesn't generate too long a comment.
cristobal commentedon Aug 31, 2022
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 commentedon Sep 8, 2022
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 thepackages/directory, and thus shouldn't get a comment that may mislead contributors.cristobal commentedon Sep 8, 2022
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 versioncommand.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.