Replies: 1 comment
-
Happy to brainstorm this idea. I think that the laid-out problem is real - people are often using Changesets "incorrectly" (I'm stretching it a little bit as there is no single way to use Changesets). The fact that you can create multiple changesets per PR is an explicit feature. It's very much by design. However, it doesn't always "click" for people. I'm not entirely sure how to achieve a great UX here though as this all boils down to some details. If we just communicate this in the CLI prompts then... nobody will actually read it 😅 Perhaps a config flag that would disallow this (require a single package per changeset) + a CLI flag that would bypass this config-level check when creating prompts would do the trick? |
Beta Was this translation helpful? Give feedback.
-
Over in backstage we're happy users of changesets, and have been using it for many years. Something that we've been struggling with quite a lot is the external contributions and how write good changesets. A particular issue that pops up very often are changesets that are written towards multiple packages at once, leading to a confusing changelog. For example:
Reading the changeset as is the information makes sense, but once you split it out into the changelogs for the
components
andtheme
packages, there's a bunch of unrelated information. Thecomponents
package doesn't decide the background colors, and thetheme
package doesn't have aButton
component.I've been thinking that it's worth tweaking the CLI UX to either outright disallow selection of multiple packages at once, or in some way heavily discourage it. That way I'm thinking you're more likely to be writing changesets for one packages at a time, but you still might have the convenience of applying it to multiple packages in the cases where that makes sense.
Beta Was this translation helpful? Give feedback.
All reactions