Aggregate releases

It’s a very popular request to aggregate all of the changelogs stuff in a single GitHub release. A lot of open-source monorepos revolve around a single project and thus creating dozens of releases with each changeset publish gets quite noisy - this is especially true for linked packages or fixed packages (FYI I’m working on introducing the fixed package groups).

I propose to introduce support for this:

type LinkedPatterns = string[];
type Linked = Array<
  | { name?: string; packages: LinkedPatterns; aggregate?: boolean }
  | LinkedPatterns
>;

Since the goal of this feature is to combine things into a single GitHub release we need something to put in the title of the release. The name option would be used for that and the created release would have such title ${name} v${version}. It IMHO makes sense to infer the name from the used scope as that would work for the majority of use cases - but that can also be left out from the MVP.

aggregate (or aggregateRelease) would be an opt-in for this feature - @changesets/action could pick this up and decide how to handle the releasing part of the things. Some people have also suggested that a single CHANGELOG could be created (that would be a copy of the aggregated release) - I think there is a value in this feature, but I’m not sure if this should automatically be enabled with just aggregate or if this requires an additional option. I’m afraid of introducing an option creep though so I would really prefer to keep this simple.

The big question is - how do we concatenate particular changelogs? How do we sort packages? My ideas:

• allow for stuff defined in packages to decide about this, for instance: packages: ['@chakra-ui/react', '@chakra-ui/*'] would tell Changesets to use the current CHANGELOG update from @chakra-ui/react first and to put everything else after that
• we could try to sort the packages based on the dependency graph, so basically try to infer the order from the graph - the packages with the most descendants would take precedence over packages with less of those. This is kinda magical and probably just a possible enhancement over the previous idea. I would keep this one out of the MVP

There is also an additional problem - some projects, like Chakra, have an “aggregate” package like @chakra-ui/react. The purpose of this package is to just reexport stuff from everything else and nothing beyond that. I think they currently just add @chakra-ui/react to each created changeset because of that. This would mean that every change in the aggregate release would get kinda duplicated because of that - as it would be described both by @chakra-ui/react and some other, inner, package like @chakra-ui/button or something. Could their workflow be adjusted with the aggregate in place in a way that they wouldn’t suffer from this problem?

Do we want to use this in Changesets itself? It feels like we fall into the “single project” category - but we are not using linked nor fixed packages at the moment. And I think it makes sense for us to keep versioning for internal packages separate from the @changesets/cli version - because we tend to introduce subtle changes there that could be seen as breaking ones. With how we are handling this today we have the freedom of creating major bumps for those packages as frequently as we want. Could we somehow allow aggregate to work in monorepos without linked or fixed packages?

@ianstormtaylor @with-heart

[thdxr]

We’re also interested in this feature at https://github.com/serverless-stack/serverless-stack

We currently have a set of fixed packages that are always bumped together. When we do a release we’d like a single tag and a single release published with the list of changes

Definitely willing to submit a PR if I could understand better of how this should be designed

Also curious if there’s a work around right now to publish a single tag with the changeset action

[paales]

@Andarist We’re very interested in these aggregated releases

Our current release notes are practically unusable on GitHub because we get a lot of duplicates which makes reading the release notes impossible.

We’ve got lots of duplicates for example:

• https://github.com/graphcommerce-org/graphcommerce/releases/tag/%40graphcommerce%2Fnext-ui%404.7.2
• https://github.com/graphcommerce-org/graphcommerce/releases/tag/%40graphcommerce%2Fmollie-magento-payment%403.2.9
• And a ton more

In an ideal scenario we’d like to:

• Keep the separate versioning of the individual packages because we have multiple ‘groups’ of packages. We are considering linking those groups together based on a wildcard, but we will always have multiple groups.

• The ‘root’ (@graphcommerce/graphcommerce) should catch all changes of all child packages and have the release notes aggregated there. This may also be versioned, but I don’t reallly care 😃

• We don’t want to have separate releases on GitHub for separate packages as this just isn’t clear. We only want to create a GitHub release for the root package, all other packages can have their CHANGELOG.md and their git tag of course, but not a GitHub release note.

Anything I can help with to move this forward?