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