Skip to content

Feature Request: warn user on a per package basis #11

Open

Description

@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

Activity

  1. Noviny commented on Sep 23, 2020

    @Noviny
    Contributor

    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.

  2. jorenbroekema commented on Sep 27, 2020

    @jorenbroekema
    Author

    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.

  3. Noviny commented on Oct 1, 2020

    @Noviny
    Contributor

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

  4. Noviny commented on Oct 1, 2020

    @Noviny
    Contributor

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

  5. cristobal commented on Aug 31, 2022

    @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.

  6. nwalters512 commented on Sep 8, 2022

    @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.

  7. cristobal commented on Sep 8, 2022

    @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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions